Vyatta To Checkpoint VPN Howto Guide
Vyatta To Checkpoint VPN Howto Guide
1 Introduction The idea of this document is to show you the screen shots and configuration necessary to establish an IPSEC tunnel between Checkpoint NGX R75 (no HFAs) to Vyatta VC 6.2 The author of the document had no previous experience of Vyatta and the third party (managing the Vyatta) had no previous experience of managing Checkpoint products. 2 Aim To help someone troubleshoot, or establish a vpn tunnel between Checkpoint and Vyatta products. 3 Roles & Responsibilities
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 1 of 25
Customer and third party to have very clear understanding of their respective firewall products, and a very clear understanding of establishing and troubleshooting VPNs. 4 Procedure Here is the config for the checkpoint end of things As this was established on production equipment, and for security reasons, the screen shots are sometimes obfuscated. You will have to transpose your own IP addressing into the procedure to ensure the tunnel works. Be careful if initially enabling/disabling PFS (Perfect Forward Secrecy) otherwise (if PFS is disabled on the Checkpoint) then the tunnel will establish one-way. The Vyatta end will be able to ping the Checkpoint protected network, but not vice versa. One thing we noticed, which needs careful consideration, is that in the event that the Checkpoint firewall doesnt have the VPN domain manually defined in the Checkpoint object (Topology) then it will be necessary to create tunnels on the Vyatta to EVERY network directly connected to the Checkpoint firewall. For example, imagine you have 5 network interfaces in your Checkpoint firewall like this 10.0.5.0/24 172.16.60.0/24
Prepared By: Department
Carrwood Park Swillington Common Road Selby Road Leeds LS15 4LG T E W 0113 341 0123 [email protected] www.itogether.co.uk
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 2 of 25
192.168.1.0/24 172.17.1.0/24 Internet range x.x.x.x/30 You will need to create VPNs to all of the ranges other than the Internet range. This is because the Checkpoint firewall (if NOT set to have a manually defined encryption domain) will offer all of its networks and topology to the Vyatta. This will confuse the Vyatta as normally you only define the single network or networks you want in your encryption domain. This seems to be only an issue with Checkpoint to non-Checkpoint products. If you create a Checkpoint to Checkpoint tunnel, the products are much more forgiving when it comes to topology.
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 3 of 25
Checkpoint firewall object, defined in this case as the external/Internet facing IP address
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 4 of 25
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 5 of 25
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 6 of 25
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 7 of 25
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 8 of 25
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 9 of 25
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 10 of 25
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 11 of 25
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 12 of 25
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 13 of 25
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 14 of 25
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 15 of 25
The log file shows how initially the tunnel failed (because PFS was enabled on the Vyatta end) then the pings and RDP test connections initiated from the Checkpoint side worked fine. Notice how the tunnel timeouts for Phase1/2 had been changed from their Checkpoint default settings. Notice how NAT had been disabled, and the tunnel used simplified mode so that all traffic was allowed to pass for testing At a later stage a rule could easily be setup for the VPN community to filter traffic by source and destination and service type.
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 16 of 25
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 17 of 25
} port-group web { port 80 port 443 } } ipv6-receive-redirects disable ipv6-src-route disable ip-src-route disable log-martians enable name eth0-in { default-action drop rule 10 { action accept description ESTABLISHED state { established enable related enable } } rule 20 { action accept description ICMP_ECHO_REQ icmp { type-name echo-request } protocol icmp } rule 30 { action accept description WEB destination { group { port-group web } } protocol tcp } rule 40 { action accept description RDP destination { port 3389 } protocol tcp source {
Prepared By: Department
Carrwood Park Swillington Common Road Selby Road Leeds LS15 4LG T E W 0113 341 0123 [email protected] www.itogether.co.uk
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 18 of 25
group { address-group remote-group } } } rule 50 { action accept description NRPE destination { port 5666 } protocol tcp source { group { address-group nagios-group } } } rule 60 { action accept source { group { network-group vpn-subnets } } } rule 70 { action accept destination { port 902 } protocol tcp } } name eth0-local { default-action drop rule 10 { action accept description ESTABLISHED state { established enable } } rule 20 { action accept description ICMP-ECHO-REQ
Prepared By: Department
Carrwood Park Swillington Common Road Selby Road Leeds LS15 4LG T E W 0113 341 0123 [email protected] www.itogether.co.uk
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 19 of 25
icmp { type-name echo-request } protocol icmp } rule 30 { action accept description SSH destination { port 2222 } protocol tcp source { group { address-group admin-group } } } rule 40 { action accept description SNMP destination { port 161 } protocol udp source { group { address-group snmp-group } } } rule 50 { action accept description ESP protocol esp } rule 60 { action accept description IKE destination { port 500 } protocol udp } rule 70 { action accept
Prepared By: Department
Carrwood Park Swillington Common Road Selby Road Leeds LS15 4LG T E W 0113 341 0123 [email protected] www.itogether.co.uk
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 20 of 25
source { group { network-group vpn-subnets } } } rule 80 { action accept description GRE protocol gre } rule 90 { action accept description PPTP destination { port 1723 } protocol tcp } } receive-redirects disable send-redirects enable source-validation disable syn-cookies enable } interfaces { ethernet eth0 { address 178.251.234.xyz/30 duplex auto firewall { in { name eth0-in } local { name eth0-local } } hw-id 00:50:56:80:01:94 smp_affinity auto speed auto } ethernet eth1 { address 10.255.15.1/24 duplex auto hw-id 00:50:56:80:01:9a smp_affinity auto
Prepared By: Department
Carrwood Park Swillington Common Road Selby Road Leeds LS15 4LG T E W 0113 341 0123 [email protected] www.itogether.co.uk
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 21 of 25
speed auto } loopback lo { } } service { nat { rule 1 { description "VPN EXCLUSION - 192.168.2.0/23" destination { address 192.168.2.0/23 } exclude outbound-interface eth0 source { address 10.255.15.0/24 } type source } rule 2 { description "VPN EXCLUSION x.x.x.x/24" destination { address x.x.x.x/24 } exclude outbound-interface eth0 source { address 10.255.15.0/24 } type source } rule 10 { description "DEFAULT SNAT" outbound-interface eth0 outside-address { address 178.251.234.194 } source { address 10.255.15.0/24 } type source } rule 20 { destination { address 178.251.234.194 port 902
Prepared By: Department
Carrwood Park Swillington Common Road Selby Road Leeds LS15 4LG T E W 0113 341 0123 [email protected] www.itogether.co.uk
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 22 of 25
} inbound-interface eth0 inside-address { address 10.255.15.50 } protocol tcp type destination } } ssh { port 2222 protocol-version v2 } } system { config-management { commit-revisions 20 } console { device ttyS0 { speed 9600 } } gateway-address *.*.*.* host-name fw100544 login { user 100544 { authentication { encrypted-password ****** plaintext-password "" } level admin } } name-server 193.169.90.4 name-server 193.169.91.4 ntp { server 0.vyatta.pool.ntp.org { } server 1.vyatta.pool.ntp.org { } server 2.vyatta.pool.ntp.org { } } package { auto-sync 1
Prepared By: Department
Carrwood Park Swillington Common Road Selby Road Leeds LS15 4LG T E W 0113 341 0123 [email protected] www.itogether.co.uk
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 23 of 25
repository community { components main distribution stable password "" url http://packages.vyatta.com/vyatta username "" } } syslog { global { facility all { level notice } facility protocols { level debug } } } time-zone GMT } vpn { ipsec { esp-group ESP1 { compression disable lifetime 3600 mode tunnel pfs dh-group2 proposal 1 { encryption 3des hash md5 } } ike-group IKE1 { dead-peer-detection { action restart interval 30 timeout 120 } lifetime 28800 proposal 1 { dh-group 2 encryption 3des hash md5 } } ipsec-interfaces {
Prepared By: Department
Carrwood Park Swillington Common Road Selby Road Leeds LS15 4LG T E W 0113 341 0123 [email protected] www.itogether.co.uk
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 24 of 25
interface eth0 } site-to-site { peer 86.xx.rr.zz { authentication { mode pre-shared-secret pre-shared-secret xxxxxxxxxxxxxxx } connection-type initiate ike-group IKE1 local-ip 178.251.234.194 tunnel 1 { allow-nat-networks disable allow-public-networks disable esp-group ESP1 local { subnet 10.255.15.0/24 } remote { subnet x.x.x.x/24 } } } } } }
Simon Richardson Professional Services 1.0 30th August 2011 Released Page 25 of 25