Internal SSL client can't connect to External SSL site ?

[siatoz]

An internal client using clinet certificates can't connect to the external SSL site. After checking the SEF6.5.2 logs, the error is that the first packet is not a Hello, and as such the SEF won't let it out.
Some needed info, The client is Windows based using IE5.x through a Proxy to the internal interface of the SEF. The Web site is an internet banking site. Both client and server certs are used.
Without the SEF the client can connect. This is not the only site that is giving me this error. SSL to a site that only uses server certs works fine.

Can anyone please help?

 

[billhome]

Read your manual on how to run a tcpdump. Check and confirm that packets are coming and going from both the internal client and the firewall and from the firewall to the extenal server. There might be some kind of port translation either going on or lacking. Identify the ports that the packets are coming and gong on. You may have to add an address transform for that specific client. In otherwords when the packet shows up at the server with the firewall's IP address the server may balk. A static NAT pool with the address transform may resolve this. Run the tcpdump and post what you capture.

 

[siatoz]

As mentioned, the log on the SEF shows that the outgoing packet has the appropriate destination and port, it shows that packets are going fro the client to the SEF (otherwise there would be no log of the activity) and the fact that I can connect to other server cert only SSL sites proves that packets are going in and out of my private network to the internet. NAT is happening quite happily. The issue that I am having is that the SEF says that the first message from the client to the external server is not a HELLO message and as such this can't be a valid connection and doesn't let it through. The same thing happens on another system that uses port 434 on the external server. I have set the filters appropriately for the port, but the SEF logs that the first message from the client is not a HELLO and as such won't allow it to pass. Is is possible to tell the SEF to let these particular SSL client packets through? Simon Powell.
MCSE,MCNE,Master CIW Admin,MCT,CNI,CIW CI.

 

[billhome]

Good one. I've heard of problems with esmtp and raptor which I think may be a similiar issue. There are ways to pass the traffic that you are passing with raptor but due to the fact that it is a proxy based firewall and not a simple packet filter I think that it is going to require some extra steps. I'm not really sure how I would do it but it sounds as though it could be a project. You are using the http daemon I assume. The ports that you are trying to use for SSL are probably already within either the http daemon settings or configured within your rule in allowed services using the configure button. It may be the daemon alone that is causing this problem. By disabling the daemon and creating a gsp you could probably pass the traffic but this might open you up to more vunerabilities that you would want. I'm really curious on how you end up resolving this. If you could post it when you do I would appreciate it. Good luck.

 

[siatoz]

Thanks for the posts. I think I may have it liked. I'm in the process of testing a theory. I don't think it is a problem with the SEF but in fact may be the internal proxy and how it forwards SSL client messages. When we try and access the same site from the SEF console all is happy. I will post once I have found the solution.


Simon Powell.
MCSE,MCNE,Master CIW Admin,MCT,CNI,CIW CI.

 

[billhome]

getting there from the firewall should happen anyways. The firewall itself is not bound to the rules that affect systems behind it.

 

[siatoz]

But the httpd is logging the messages happily so I assume that the httpd is handling the packets.
Considering that the httpd was the one logging the errors saying that the packet was not a hello but when I go from the console it shows all the packets with the appropriate destination ports and addresses are happy. Are you suggesting that because I am going from the console that the Httpd doesn't do the same checks? Simon Powell.
MCSE,MCNE,Master CIW Admin,MCT,CNI,CIW CI.

 

[billhome]

Httpd is not providing the same function from the firewall as it does from behind the firewall. Httpd is logging the traffic, you are right, but you are not bound to the httpd controls and proxy characteristics as you are from behind the firewall.