SMB VPN Tunnel for LAN, WLAN to internet should be able to connect via Endpoint - possible?

[Steffen_Appel]

We have some SMB (1530 ) out there, which have a VPN tunnel to the datacenter.

We are now using the WLAN too, but this has open intranet access and no VPN tunnel, but users with the endpoint clint should be able to connect via the RA VPN, so far it does not work - any ideas how to get it working?

[G_W_Albrecht]

users with the endpoint client should be able to connect via the RA VPN - to which GW ? If datacenter is VPN peer to site behind 1530, RA connection to 1530 will make connection to datacenter available to RA VPN users.

[Steffen_Appel]

RA should connect to the same VPN GW.

The WLAN is not in the encryption domain and the RA connection fails (probably as the external IP is the same for both VPNs on both sides).

[G_W_Albrecht]

Why that ? Can you show that weird topology ?

[Steffen_Appel]

Thats not a weird topology and I explained it above.

Anyhow here again:

LAN behind SMB (10.x)  in Enc Domain

     |

 1530 --(Official IP)-----------------------------------Internet--------------------------- VPN-GW------ Data Center

    |

 WLAN with internet access (192.x) outside the enc domain

Devices in the WLAN, which have a RA Client should be able to establish a VPN tunnel via RA.

[Kryten]

Maybe I am missing something here, but I think you should use the existing secured connection(VPN) between the 1530 and the VPN GW instead of establishing RA Sessions to it additionally. You would just need to add the WLAN subnet to the encryption domain and configure some access polices.

Establishing two separate VPN connections from the same IP to the same IP does not make much sense.

[Steffen_Appel]

Of course it works when I add the WLAN to the enc domain, but that is not the use case. Just think of the WLAN as a "public" WLAN hotspot, but still users should the able to connect via RA.

[Kryten]

ah ok, I wasn't aware that the WLAN is also for guests.

I am not sure if there is any solution for this case that does not involve using additional IP Adresses or something like Identity Awareness to tell the users apart.

As long as the VPN connections come from the same IP and use the same ports/protocol, the VPN GW will have troubles telling them apart, as it will assume they belong to the same VPN.

[PhoneBoy]

I assume the clients are being NATted to the same public IP of the SMB gateway, correct?
When you say it doesn’t work, what precise behavior is observed?
What debugging have you done?

I recommend engaging the TAC in parallel here.

[Steffen_Appel]

Yes the 1530 only has one public IP - so all outbound traffic gets this IP.

It seems like the client finishes phase-1 and fails in phase-2 (with an internal error). The WLAN network is excluded in the crypt.def so the 1530 does not try to put the traffic in the tunnel.

[PhoneBoy]

I would think you could simply define the WLAN network as not part of the Encryption Domain (either locally or centrally managed).
That would be far better than using cpypt.def hacks, or is there a specific reason you're doing it that way?

[Steffen_Appel]

The WLAN is not part of the encryption domain, but CP automatically includes the GW in the enc domain, which we excluded via crypt.def, anyhow both ways it did not work.

[PhoneBoy]

Right, that is a situation where crypt.def is needed (removing the gateway from the encryption domain).
I suspect this is a bug of some sort, thus the TAC should be involved.

[skandshus]

The reason you're seeing this is because the way Checkpoint create site-2-site tunnels is that they do not ONLY include the encryption "domain" A.K.A the Subnet you define, no the Gateway external interface/public ip/wan side is also included into that.

So what happens is that when your Laptop tries to connect its trying to connect to the "wan" ip of the remote datacenter Gateway, which sees that youre trying to send Vpn traffic from a network which belongs to a Site-2-site tunnel your datacenter gateway has with the gateway on the site that your laptop is sitting behind(though in another subnet not part of the encryption domain)

you need to manually "remove" .

I've been struggling with seeing what the purpose is here for checkpoint doing that, and not even give the slightest hint on what's actually going on if your check logs etc... let alone create an easy way "out" so you're actually able to send traffic to the "remote interface" and not having it forced into the vpn tunnel.

[PhoneBoy]

Yes, and he’s excluded it from the encryption domain already…still having an issue.

I suspect seeing Remote Access traffic from the same IP as is used for a Site-to-Site VPN is problematic.
This is either a bug (requiring a TAC case to resolve) or this is ultimately not a supported configuration.

[Steffen_Appel]

We have excluded the GW public IP as described, but it still did not work.

[G_W_Albrecht]

I would suggest to ask TAC !