Route traffic between two IPSec tunnels

michall

Hi,

We have 3 sites: A,B and C

A and B are pfSense 2.4.4p2. C is our client's box so I actually don't know what they use but it doesn't really matter.

Local addresses are as follows:
A - 10.11.40.1/24
B - 10.11.20.1/24, 10.100.100.1/24
C - 10.200.200.0/24

I have 2 IPSec tunnels: first between sites A and B, second between sites B and C (Phase2: 10.100.100.0/24 <->10.200.200.0/24).

Traffic from A to B - works without problem.
Traffic from site B to C is "hidden" using Outbound NAT under B-site local address (10.100.100.1) and also works ok (I can access site C from site B no problem)

However I need to access site C from site A via site B.
So at site B traffic incoming from site A has to be decrypted, hidden under address 10.100.100.1 and then encrypted again but now for site C.

What combination of routing/nating/or else I have to do to make this work?
I've spent a better part of two days at it without success - I'm lost, help...

Cheers
Mike

Derelict

Create two more tunnels:

A 10.11.40.0/24 <-> 10.200.200.0/24 B

B 10.11.40.0/24 <-> 10.200.200.0/24 C

You cannot use the same NAT address because, if I understand what you're saying correctly, site C has a tunnel from 10.200.200.0/24 to 10.100.100.1/32 You cannot have another tunnel that they see as the same traffic selectors but NAT to a different network on your side. The other side won't know which one to use.

You could have them establish another connection with you natting 10.11.40.1/24 to 10.100.100.2/32, say, but it really depends on what both sides expect for traffic selectors.

A major factor in this is how connections flow inside the tunnel. If site C establishes connections to you it gets more difficult.

You should probably outline all of the phase 2 entries, complete with the NAT settings there.

michall

Thank You for Your reply. I tried to keep it as simple as possible but maybe too simple ;-) Here is more detailed description.

First of all, I cannot enforce any change in configuration on site C - this is huge, global corp and We are just tiny subcontractor in comparison. They actually enforced us to use this 10.100.100.0/24 network on our side. On the bright side connections are so far initiated only on our side.

Phase 2 A <-> B
Tunnel_1: 10.11.40.0/24 <-> 10.11.20.0/24
Tunnel_2: 10.11.40.0/24 <-> 10.100.100.0/24

No NAT in these tunnels. Everything works ok.

Phase 2 B <-> C
Tunnel_1: 10.100.100.0/24 <-> 10.200.200.0/24

NAT Outbound @ site B:
Inteface (IPsec), Source (10.100.100.0/24), Destination (10.200.200.0/24), NAT Address (10.100.100.1)

So any connection made to site C from site B at site C is visible as coming from single address 10.100.100.1. This also works great.

In order to access site C from site A, among other things I tried to add something like this
Static route @ site A:
10.200.200.0/24 gw 10.100.100.1 (or in second attempt: 10.200.200.0/24 gw 10.11.20.1)
and
NAT Outbound @ site B:
Inteface (IPsec), Source (10.11.40.0/24), Destination (10.200.200.0/24), NAT Address (10.100.100.1)
but it doesn't work...

I've also tried to add third tunnel between A and B
Tunnel_3: 10.11.40.0/24 <-> 10.200.200.0/24
bit it didn't help also...

It seems like pfSense is not able to receive traffic on IPsec interface and then send it back via the same interface but to a different tunnel. What am I missing?

Adrianoebm

Hi,
I have exactly the same problem, this is called hairpinning VPN if i found a solution i will post it here.
regards.

Derelict

@michall I don't think you can do that without cooperation from the other side.

About all I can suggest is seeing if the other side will allow these tunnels to come up:

Phase 2 B <-> C
Tunnel_1: 10.100.100.0/24 <-> NAT 10.100.100.1/32 <-> 10.200.200.0/24
Tunnel_2: 10.11.40.0/24 <-> NAT 10.100.100.2/32 <-> 10.200.200.0/24

There would, of course, also be a tunnel between A and B

10.11.40.0/24 <-> 10.200.200.0/24

Some IPsec implentations will allow the other side to make a tunnel for a netmask smaller than the one in their policy. Some will not.

Note that if the other side tries to initiate for 10.100.100.0/24 it will fail because there would be no policy on your side for that.

You might also try this tunnel between A and B

A: 10.11.40.0/24 <-> NAT Address 10.100.100.2 <-> 10.200.200.0/24
B: 10.200.200.0/24 <-> 10.100.100.2/32

But you can't also have this tunnel in that case:

A: 10.11.40.0/24 <-> 10.100.100.0/24
B: 10.100.100.0/24 <-> 10.11.40.0/24

You have pretty much painted yourself into a corner here.

Depending on the addresses you need, you could split 10.100.100.0/24 in two:

Site A: 10.100.100.128/25
Site B: 10.100.100.0/25

Then both sites would be routable and distinct from each other but would both match the tunnel to Site C that you say cannot be changed.

You could experiment to see if a Routed IPsec will come up to the other side. You would then be free of using traffic selector policies to match the traffic that should go over the tunnel using the routing table on your side instead. You would have more NAT flexibility in that case.

https://www.youtube.com/watch?v=AKMZ9rNQx7Y

michall

I've finally done it.
@Derelict Thank You! I've actually managed to find a few ways to make it work. Learned a lot in the process.

Best solution I found was:

Add Phase2 tunnel between site A and B like this: site A (10.11.40.0/24) <-> site B (10.200.200.0/24)
Modify Phase2 tunnel between site B and C and use NAT on it: site B (10.11.0.0/16 -NAT-Address-> 10.100.100.1) <-> site C (10.200.200.0/24). No configuration change was required on site C which wasn't an option anyway :-)
Remove Outbound NAT rule @ site B that hid traffic to site C under single IP address (10.100.100.1). This rule is no longer required because source address translation is now handled by Phase2 tunnel configuration itself.
Remove 10.100.100.0/24 network from site B. I no longer need this network because Phase2 B <-> C now matches my primary local subnets.

Final config to summarize it for anyone with similar problem (access site C from site A via site B).

LAN addresses are as follows:
site A - 10.11.40.1/24
site B - 10.11.20.1/24
site C - 10.200.200.1/24
site C will accept traffic only from address 10.100.100.1

Phase 2 A <-> B
Tunnel_1: 10.11.40.0/24 <-> 10.11.20.0/24
Tunnel_2: 10.11.40.0/24 <-> 10.200.200.0/24

Phase 2 B <-> C
Tunnel_1: 10.11.0.0/16 -NAT-Address-> 10.100.100.1 <-> 10.200.200.0/24

Correct me if I'm wrong but my conclusion is that pfSense will not send traffic to IPsec tunnel if this traffic does not originate from network matching configured Phase2 networks even if You configure Outbound NAT for non-P2-matching subnet and translate it to match configured P2. Maybe it is obvious to some people but it wasn't for me. Before pfSense I've used Vyatta/VyOS and P2 source network evaluation took place AFTER outbound NAT was performed.

Other solutions I've tested and they worked (sort of):

To original configuration add Phase2 between site A (10.11.40.0/24 -NAT-Address-> 10.100.100.2) and site B (10.200.200.0/24). This way traffic coming from site A matched site's B local network used in Phase 2 tunnel between B and C.
Split site's B network into 2 as @Derelict suggested:
a. Split site's B subnet (10.100.100.0/24) into two (10.100.100.0/25 and 10.100.100.128/25)
b. Add Virtual IP Alias for LAN @ site A (10.100.100.129/25)
c. Create Phase2 between site A (10.100.100.128/25) and site B (10.200.200.0/24)
d. For the servers that are located @ site A and need to access site C, I've assigned addresses from 10.100.100.128/25 subnet and created static route for subnet 10.200.200.0/24 with gw 10.100.100.129. This way servers from site A will "show up" at site B with addresses that match 10.100.100.0/24 P2 between site B and C.
Other variant of 2nd solution is to use routed IPsec between A and B. Haven't actually tested routed IPsec with splitting the network but I'm positive it would work. Tested routed IPsec without splitting the 10.100.100.0/24 subnet but it didn't work.
Created OpenVPN server (p2p) between A and B. It also didn't work without splitting the 10.100.100.0/24 subnet. However it did work with splitting the network like in previous solutions.

Solution number 2 config for complete picture:

LAN addresses are as follows:
site A - 10.11.40.1/24, 10.100.100.129/25
site B - 10.11.20.1/24, 10.100.100.1/25
site C - 10.200.200.1/24

Phase 2 A <-> B
Tunnel_1: 10.11.40.0/24 <-> 10.11.20.0/24
Tunnel_2: 10.100.100.128/25 <-> 10.200.200.0/24

No NAT in these tunnels.
Servers @ site A that need to access site C have addresses assigned from 10.100.100.129/25 subnet and static route to 10.200.200.0/24 using 10.100.100.129 as gateway.

Phase 2 B <-> C
Tunnel_1: 10.100.100.0/24 <-> 10.200.200.0/24

NAT Outbound @ site B:
Interface (IPsec), Source (10.100.100.0/24), Destination (10.200.200.0/24), NAT Address (10.100.100.1)
Servers @ site B that need to access site C have addresses assigned from 10.100.100.0/25 subnet and static route to 10.200.200.0/24 using 10.100.100.1 as gateway.

Note: This Outbound NAT @ site B is not required in order for this to work but it's requirement from our Customer who controls site C to "show up" at their end only as 10.100.100.1.

Hope it will be useful to somebody :-)