Client VPN and then Site to Site VPN traversal (possible?)

Andynz · Oct 16, 2015, 3:20 AM

Hi All, (Please let me know if a diagram would help articulate the question clearer )

I'm using PFSense firewalls in a lab environment imitating a dual DC deployment. I have a IPSEC site to site VPN between the firewalls with unique network ranges on either side.

Traffic across the Site to Site VPN is fine in both directions.

The issue I've come across is when configuring OpenVPN client to site VPNs on each gateway. The intention is to terminate a VPN on PFSense1 and be able to not only access local subnets but also have the client subnet range encrypted across the site to site VPN to access remote / DC2 subnets.

Please note that I encrypt all traffic via the gateway in this setup.

Please also note that both DCs have unique VPN client networks (172.30.254.0/24 and 172.30.194.0/24 respectively).

What I'm finding is that client to site Comms are working (I.e I see traffic reach the gateway with a destination of the remote DC subnets but the PFSense doesn't appear to want to send the traffic to the crypto engine to reencrypt onto the site to site VPN). Is this a limitation?

Is this an issue where traffic that arrives on the OpenVPN virtual interface isn't interrogated by the crypto engine like traffic which arrives on the standard interfaces which you configure at install?

Please note that I have the following IPSec Configuration in place and appropriate policy applied on the OpenVPN interface to permit the traffic. A phase2 SA never gets created.

DC 1 Configuration;

IPSEC -
Local:172.30.254.0/24 (DC1 client VPN subnet)
Remote:172.16.90.0/27 (DC2)
Service: ANY (TCP/UDP)

OpenVPN interface -
Source:172.30.254.0/24
Destination:172.16.90.0/27
Service: ANY (TCP/UDP)

DC 2 Configuration;

IPSEC VPN P2:
Local: 172.16.90.0/27
Remote: 172.30.254.0/24
Service: ANY (TCP/UDP)

IPSEC interface (expect traffic on)
Source: 172.30.254.0/24
Destination: 172.16.90.0/27
Service: ANY (TCP/UDP)

I'm not sure if my understanding is right around the order of operations but logically I think it would work something like this (can anyone confirm this for me please? :) )

traffic is sourced and destined for a network defined in VPN Site to Site configuration so phase 2 SA should stand up (if both sides match). Or possibly route table lookup first which knows that the destination network is destined to be encrypted based on phase 2 IPSec configuration?

Is this scenario achievable or is there a bit of code missing that prevents traffic arriving on OpenVPN vinterfave from ever reaching crypto engine?

Any incite to this behaviour would be hugely appreciated. Basically if I can get this working then no matter which client VPN the users are connected to, they will be able to access both DC networks.

My current work around is;
1. Establish c-s VPN to DC1.
2. Establish c-s VPN to DC2 across DC1 VPN.
3. Specify unique DC ranges in split tunnel arrangement to ensure client route table is populated with the correct routes across each tunnel. This is inefficient and tunnelblick on Mac seems to break when the primary tunnel fails (i.e client can't reach any DNS servers (one in each DC) so when DNS lookup occurs to find gateway on reconnect, it fails as DNS fails. (Client doesn't appear to flush DNS on disconnect - another issue but referenced here for a little more context).

I'm hoping someone can tell me if it's supposed to be possible or whether this situation is something that could be requested as an extra feature.

Many thanks,
Andy

Andynz · Oct 16, 2015, 6:05 AM

So turns out I was being a muppet.

Resolution in this case is as follows for anybody who wants to do something similar in the future;
1. Confirm SA on Site to Site VPN between Client VPN Subnet and the intended destination.
2. If SA isn't up but the configuration checks out, bounce VPN after adding new phase 2 configuration.
3. Confirm SA is active. Connect to SiteA VPN gateway and test connectivity. Works a charm.

Verification as below; connected to SiteA Gateway using OpenVPN, successful pings across.

$ ping 172.16.91.10
PING 172.16.91.10 (172.16.91.10): 56 data bytes
64 bytes from 172.16.91.10: icmp_seq=0 ttl=62 time=111.347 ms
64 bytes from 172.16.91.10: icmp_seq=1 ttl=62 time=106.847 ms
64 bytes from 172.16.91.10: icmp_seq=2 ttl=62 time=83.631 ms
^C
–- 172.16.91.10 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 83.631/100.608/111.347/12.145 ms

$ ping 172.16.61.10
PING 172.16.61.10 (172.16.61.10): 56 data bytes
64 bytes from 172.16.61.10: icmp_seq=0 ttl=63 time=97.420 ms
64 bytes from 172.16.61.10: icmp_seq=1 ttl=63 time=133.841 ms

SiteA firewall logs;
iface ovpns1 - sucessful permit icmp source 172.30.254.2 destination 172.16.61.10
iface ovpns1 - successful permit icmp source 172.30.254.2 destination 172.16.91.10
SiteB firewall logs;
iface IPSEC - succesful permit icmp source 172.30.254.2 destination 172.16.91.10 :)

Beautiful. Taking a bit of time to look at the basics, walking away and having a coffee and some food followed by some more investigation = success.

Hope this helps anyone who may wonder the same thing in future.

So in summary; For this to work;

1. You have to specify the individual OpenVPN subnet under network tab on SiteA firewall IPSEC VPN configuration (phase 2).
2. You have to permit the traffic on the OpenVPN interface for traffic entering SiteA firewall.
3. You have to specific the reverse phase 2 configuration on SiteB and manually enter the OpenVPN client subnet from SiteA.
4. You have to permit traffic on the IPSEC interface of DC2 to its intended destination.

It's Friday so time to have a beer or five! :)

kapara · Feb 9, 2016, 10:11 AM

I am trying to do the same but confused as to your explanation. Any screenshots would be great!