I would see the outbound connection on 21 then an inbound connection from the customer on >1023 but the log entry for the >1023 connection back in from the customer was an alert from SmartDefense.I didn't see any real drops. For the life of me I could not get this connection to work through NGX R61. These systems are using static NAT's and work perfectly with the 4.1 FW-1. We have two client computers on our DMZ that does an outbound connection to a customer.
![check point vpn 1 firewall 1 check point vpn 1 firewall 1](https://i.ebayimg.com/images/g/l~cAAOSwVcFXOcph/s-l300.jpg)
Everything when flawlessly except for 2 SSL over FTP connections.
CHECK POINT VPN 1 FIREWALL 1 UPGRADE
Since there is no direct upgrade from 4.1 to NGX, I had to recreate all the rules and such. We have a multi-DMZ segment design with multiple inbound (IIS DNS SMTP.etc) and outbound (SMTP HTML DNS.etc) connections. We replaced it with 2 SecurePlatform NGX R61 enforcement modules with HA.
CHECK POINT VPN 1 FIREWALL 1 WINDOWS
I currently went through a swap of a CheckPoint 4.1 FW running on Windows NT 4.0 (this was before my time.don't shot me :).). It can be made to work with Static NAT.įAQForm () FAQs.Class: ServicesFAQs () FAQs.OS: FAQs.Version: This is because FireWall? ()-1 is unable to see the "control" portion of the connection and cannot "munge" the ports to work with HIDE NAT. Note that in no case will FTP over SSL be supported with HIDE Network Address Translation (NAT). Source () Destination () Service () Action () ftp-client ftp-server ftp-ssl-control accept ftp-server ftp-client ftp-ssl-data accept The rulebase to permit access looks like the following: In other words, ftp-ssl-data accepts connections with a destination port of any TCP high port provided the source port is 989. In this case, you simply need to create the following TCP services:įtp-ssl-data: port number ">1024" (greater than 1024), source port 989
![check point vpn 1 firewall 1 check point vpn 1 firewall 1](http://3.bp.blogspot.com/-ALwBqEZAt5g/VBXu0av_jOI/AAAAAAAAC40/UR8hHmTG-Qs/s1600/vsx3.png)
Some variants of FTP over SSL operate over different ports using port 990 for control and port 989 for data. Some people have been able to get this to work by simply applying FTPAndNewlines (), assuming the ports used are the standard TCP port 21 for control and 20 for data. VPN-1/FireWall-1 therefore cannot predict the FTP ports used by the FTP over SSL session.
![check point vpn 1 firewall 1 check point vpn 1 firewall 1](https://mkh-electronics.com/wp-content/uploads/2017/04/Check-Point-UTM-1-Edge-X-VPN-Firewall-Router-SBX-166LHGE-5-2.jpg)
The reason for this is simple: A firewall cannot inspect the FTP control connection because it is encrypted. Firewalls do not normally pass FTP connections encrypted with SSL commonly referred to as FTP over SSL.