Problems with multiple 1550 appliance behind NAT device (same external IP) and VPN

[Oliver-Hamel]

Hi,

we are facing problems with central managed 1550 devices (LSM & Provisioning) behind NAT device (several 1550 coming from same public IP to VPN center).

The IKE phase I in center is mapped to the public IP of the peer (1550 behind NAT) instead of another identifier like internal ID or DN.
Therefore only one 1550 can have a valid IKE phase I.
The next 1550 with the same public IP is overwriting the exisiting phase I with a new phase I (which is only valid for this device).

[Central Security Gateway] --- (VPN) --- [NAT Device] --- Satellite 1550
                                                --- (VPN) --- [NAT Device] --- Satellite 1550

Is there a solution to connect several 1550 connecting to VPN Center with same public IP?

Thanks

Oliver

[PhoneBoy]

Are the gateways authenticating VPN with certificates?

[Oliver-Hamel]

Yes, all 1550 are central managed DAIP, fetching policy from LSM profile.
Mgmt and VPN gateway are R80.40 GA.

[G_W_Albrecht]

You have to use as many public IPs on the NAT device as the number of 1550 appliances you have, then all is good !

[Oliver-Hamel]

Is there a way to connect several 1550 sattelites behind same public IP?

RL example:
Almost 900 1550 connecting to VPN center. They are behind Carrier-Grade-NAT gateway (CGNAT).
There always will be a lot of them reaching the VPN center with the same public IP.

Other vendors can handle this.
We have certificate auth here..

[Wolfgang]

Oliver,

I remember there was a problem with Edge devices Site-to-Site VPN between Central Security Gateway and DAIP Edge gateways located behind the same NAT... 

But the workaround does not work for you if you are using SmartProvisioning. 

The sk article is written for older devices ( UTM Edge device ) and I'm not sure if the same limitation exist with embedded GAiA devices. If you want to have 900 devices you should open a TAC case or ask your local Check Point engineer to get a valid answer.

[Oliver-Hamel]

Yes, we are using SmartProvisioning.
I've seen the SK. Edge is way yesteryear. 😉

Started walking the way via local CP contacts and TAC..

Wanted to discuss here as well.
Even IKEv1 aggressive mode and IKEv2 is not supported for 1550 DAIP with LSM/Prov.

Maybee one had/has an idea to overcome this situation?!

[Timothy_Hall]

Pretty sure that if your 1550s are trying to use a standard site-to-site IPSec VPN that this won't work behind a single intervening NAT address.  Each 1550 will need its own unique static NAT address to help distinguish which 1550 the IKE/IPSec traffic belongs to.  You would be facing this same limitation even if working with standard Gaia on a larger appliance.  In addition I've seen issues when a hide NAT'ed device is attempting a site-to-site IPSec VPN, and it is hidden behind the actual external interface address of the NAT box itself, and the NAT box is also handling its own IKE/IPSec traffic.  The NAT device "eats" IKE/IPSec traffic bound for the hidden box thinking that it is for itself.

As mentioned in the SK, Remote Access VPNs have numerous additional connectivity enhancements to deal with NAT situations like this due to the high prevalence of NATted connections when utilizing Remote Access VPNs.

[Andreas_Aust]

@G_W_Albrecht really helpful answer in times of short ip-addresses. That means in other words smb boxes can not work with VPN behind LTE or Carrier Grade NAT. Other Vendors have no problems with that.

[Oliver-Hamel]

There is no Remote-Acces-like-behaviour for 1550 (and even not if using LSM/Provisioning).
Edge had that.

Next: Rrolem about Remote-Access-like..
SMB peer would then come in with one IP (like office mode IP).
How to deal with firewall policy on the center? We can not distinguish IPs behind SMB on the center as all traffic would come in from one source IP (per satellite).

[G_W_Albrecht]

Then please do buy it and tell us vendor and model ! I can only tell that this is impossible with a 1550 (and even with a full-blown GAiA appliance).

[John_Fleming]

Cisco DMVPN has the same problem. spoke 1 will come up, spoke 2 will come up, spoke 1 will go down. 

Cisco FlexVPN does not. You can for sure have more then two routes behind a single hide nat and it will work.

Both are options on for example an 891 router.

I know both of these to be %100 true by rights of trail by fire. I was very upset that day.

oh.. and Silverpeak doesn't have this problem either. Interesting thing... Silverpeak doesn't use IKE for phase 1 only phase 2. They distribute phase I data via API calls.

[Timothy_Hall]

Right this is a limitation of "standard site-to-site" IKE, not a particular firewall vendor.  The proprietary extensions added to IKE for support of Remote Access VPNs by the various firewall vendors are what can deal with this.

[Andreas_Aust]

Hi Tim, you are right. Other Vendors solve this problem with dialout/in VPN extensions.

[Andreas_Aust]

@G_W_AlbrechtOver the last weekend I've done some testing with a Fortinet and two Pfsense GW's behind one nat IP. Fortinet as Center, No Problems:

FGT-622 # diag vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=PfSense_0 ver=2 serial=b 192.168.173.75:4500->192.168.173.135:1024 dst_mtu=1500
bound_if=3 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/896 options[0380]=rgwy-chg rport-chg frag-rfc run_state=1 accept_traffic=1

parent=PfSense index=0
proxyid_num=1 child_num=0 refcnt=6 ilast=28 olast=28 ad=/0
stat: rxp=3 txp=3 rxb=396 txb=180
dpd: mode=on-idle on=1 idle=60000ms retry=3 count=0 seqno=0
natt: mode=silent draft=0 interval=10 remote_port=1024
proxyid=PfSense proto=0 sa=1 ref=2 serial=1 add-route
src: 0:10.3.3.0-10.3.3.255:0
dst: 0:192.168.1.0-192.168.1.255:0
SA: ref=3 options=20282 type=00 soft=0 mtu=1422 expire=28754/0B replaywin=2048
seqno=4 esn=0 replaywin_lastseq=00000003 itn=0 qat=0
life: type=01 bytes=0/0 timeout=28790/28800
dec: spi=4975d129 esp=aes key=16 31b6ded5c382614d82d47a263c22cc93
ah=sha256 key=32 336640e0257549b27d63441250595fa98cdff3f58b24985feb73b56a3136000e
enc: spi=c1e1a6fd esp=aes key=16 561ebba0ecfcbd40ace0a6e07bbb8f6b
ah=sha256 key=32 2331155d266451dc195c163f18c17fbf39ad843094ec8e11bdad0460f60033ff
dec:pkts/bytes=3/180, enc:pkts/bytes=3/396
------------------------------------------------------
name=PfSense2_0 ver=2 serial=a 192.168.173.75:4500->192.168.173.135:4500 dst_mtu=1500
bound_if=3 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/896 options[0380]=rgwy-chg rport-chg frag-rfc run_state=1 accept_traffic=1

parent=PfSense2 index=0
proxyid_num=1 child_num=0 refcnt=6 ilast=50 olast=50 ad=/0
stat: rxp=3 txp=3 rxb=396 txb=180
dpd: mode=on-idle on=1 idle=60000ms retry=3 count=0 seqno=0
natt: mode=silent draft=0 interval=10 remote_port=4500
proxyid=PfSense2 proto=0 sa=1 ref=2 serial=1 add-route
src: 0:10.3.3.0-10.3.3.255:0
dst: 0:192.168.2.0-192.168.2.255:0
SA: ref=3 options=20282 type=00 soft=0 mtu=1422 expire=3564/0B replaywin=2048
seqno=1 esn=0 replaywin_lastseq=00000000 itn=0 qat=0
life: type=01 bytes=0/0 timeout=3590/3600
dec: spi=4975d12a esp=aes key=16 14f94d8461a30fd757f6f141032e3444
ah=sha256 key=32 7180f8a9a95e687e07cf46dcd45ce420ba6bc92935fd369c940040ab15a90f58
enc: spi=cec8193b esp=aes key=16 06bf439e0dfcc8ae0abfb564827de8d2
ah=sha256 key=32 28647f90abbf2e79bfcd0b48a75367a16a806002f087d865cee0a5db2a322f1e
dec:pkts/bytes=0/0, enc:pkts/bytes=0/0
------------------------------------------------------
name=PfSense ver=2 serial=1 192.168.173.75:0->0.0.0.0:1024 dst_mtu=0
bound_if=3 lgwy=static/1 tun=intf/0 mode=dialup/2 encap=none/512 options[0200]=frag-rfc accept_traffic=1

proxyid_num=0 child_num=1 refcnt=15 ilast=50936 olast=50936 ad=/0
stat: rxp=24330 txp=24330 rxb=3211624 txb=1459848
dpd: mode=on-idle on=0 idle=60000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
run_tally=1
ipv4 route tree:
192.168.1.0->192.168.1.255 0
------------------------------------------------------
name=PfSense2 ver=2 serial=2 192.168.173.75:0->0.0.0.0:1024 dst_mtu=0
bound_if=3 lgwy=static/1 tun=intf/0 mode=dialup/2 encap=none/512 options[0200]=frag-rfc accept_traffic=1

proxyid_num=0 child_num=1 refcnt=14 ilast=50777 olast=50777 ad=/0
stat: rxp=21773 txp=21773 rxb=2874036 txb=1306380
dpd: mode=on-idle on=0 idle=60000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
run_tally=1
ipv4 route tree:
192.168.2.0->192.168.2.255 0

Next test will be on Palo

[G_W_Albrecht]

No deal - this is not Standard IPSec VPN but using proprietary extensions.

[Andreas_Aust]

You are right, but if Standards doesn't solve your problems you have to go beyond.

[Oliver-Hamel]

My 2 cents:
Proprietary extensions will be fine.
Management and VPN peers are managed by the same central management.
Check Point VPN already is using proprietary extensions to IPsec (eg. tunnel test, supernetting, etc.).

I think there should be no problem as long as there is no 3rd party invloved.

I also think its time to move forward as IPv4-space is limited.

[Pawel_Topczewsk]

The only way to sort-it-out is to "unSIC" those DAIP devices from SMS Management. In formal words, make them as independent Locally Managed devices.

Locally Managed DAIP from Check Point can use IKEv2 with no issues. You just need to use Certificate generated/signed by SMS to establish a stable VPN Tunnel.

With Centrally Managed DAIP, does not mater if it is connected directly to SMS or over SmartLSM, You will keep a tunnel maximum for 30 minutes (with default settings) and than You will need to remove all IKE SAs (you will see like 20 entries for this DAIP) over "vpn tu" command on central VPN GW.

[Andreas_Aust]

local administration is no option when you have  to manage hundreds of devices.

[Pawel_Topczewsk]

Unfortunately, SmartLSM or SMP managed DAIP, if are after any NAT will not be able to use IKEv2 at this present moment.

[Andreas_Aust]

I know. The limitatin list seems longer as the feature list.