Site-to-site link is established but no traffic passes
-
OK, so I'm a bit confused, earlier I thought you said you never saw the reply on the side with the target. I must have misread something somewhere.
What exactly do you see at each step? Source LAN, Source IPsec, Destination IPsec, Destination LAN.
-
OK, so I'm a bit confused, earlier I thought you said you never saw the reply on the side with the target. I must have misread something somewhere.
What exactly do you see at each step? Source LAN, Source IPsec, Destination IPsec, Destination LAN.
Host in source LAN network: 192.168.13.100
pfSense on source (B): 192.168.13.1
pfSense on destination (A): 192.168.11.1
Host in destination LAN network: 192.168.11.3Source LAN:
13:53:30.280851 00:15:5d:63:de:00 > 00:15:5d:63:de:04, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 20547, offset 0, flags [none], proto ICMP (1), length 60)
192.168.13.100 > 192.168.11.3: ICMP echo request, id 1, seq 3524, length 40Source IPsec:
13:53:30.280851 00:15:5d:63:de:00 > 00:15:5d:63:de:04, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 20547, offset 0, flags [none], proto ICMP (1), length 60)
192.168.13.100 > 192.168.11.3: ICMP echo request, id 1, seq 3524, length 40Destination IPsec:
14:54:39.386746 00:0a:5e:54:40:49 > 90:e6:ba:77:6b:eb, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 126, id 20547, offset 0, flags [none], proto ICMP (1), length 60)
192.168.13.100 > 192.168.11.3: ICMP echo request, id 1, seq 3524, length 40
14:54:39.386951 90:e6:ba:77:6b:eb > 00:0a:5e:54:40:49, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 1109, offset 0, flags [none], proto ICMP (1), length 60)
192.168.11.3 > 192.168.13.100: ICMP echo reply, id 1, seq 3524, length 40Destination LAN:
14:54:39.386746 00:0a:5e:54:40:49 > 90:e6:ba:77:6b:eb, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 126, id 20547, offset 0, flags [none], proto ICMP (1), length 60)
192.168.13.100 > 192.168.11.3: ICMP echo request, id 1, seq 3524, length 40
14:54:39.386951 90:e6:ba:77:6b:eb > 00:0a:5e:54:40:49, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 128, id 1109, offset 0, flags [none], proto ICMP (1), length 60)
192.168.11.3 > 192.168.13.100: ICMP echo reply, id 1, seq 3524, length 40Is this more clear?
-
yes, much more clear.
Go to System > Advanced, Misc tab, uncheck Prefer Old IPsec SA.
-
yes, much more clear.
Go to System > Advanced, Misc tab, uncheck Prefer Old IPsec SA.
Good.
This setting was not checked on either end.
-
Are there multiple IPsec tunnels at each of these locations?
The only other thing that immediately springs to mind is that the reply traffic is going back over some other IPsec tunnel.
The traffic wouldn't show up in the IPsec capture unless it went to an active tunnel. The most common way that can happens is when Prefer old IPsec SA is on and there are "stale" SAs in place.
You might check Status > IPsec, SPDs tab, make sure there isn't something leftover there from a previous config attempt. Maybe even restart racoon under Status > Services.
-
Are there multiple IPsec tunnels at each of these locations?
The only other thing that immediately springs to mind is that the reply traffic is going back over some other IPsec tunnel.
Yes. Two other tunnels are defined at the destination network pfSense. What would make them take precedence?
I checked SPDs and all were fine here.
Thanks for all the pointers btw.
-
Are there multiple IPsec tunnels at each of these locations?
The only other thing that immediately springs to mind is that the reply traffic is going back over some other IPsec tunnel.
Yes. Two other tunnels are defined at the destination network pfSense. What would make them take precedence?
That would be: Two other Phase-1 entries are defined.
There are no other Phase-2 entries in the Phase-1 entry for this link.
-
So long as the networks do not overlap it should be OK, but if any of the tunnels that were entered first have a Phase 2 that would include the network from the other side (maybe one has 192.168.0.0/16, for example) it would break any tunnel after it.
The first match wins, taken by the order the tunnels were created. Phase 2's from all tunnels are considered, in the order of their respective Phase 1's.
-
So long as the networks do not overlap it should be OK, but if any of the tunnels that were entered first have a Phase 2 that would include the network from the other side (maybe one has 192.168.0.0/16, for example) it would break any tunnel after it.
The first match wins, taken by the order the tunnels were created. Phase 2's from all tunnels are considered, in the order of their respective Phase 1's.
Yes. That's what I thought. This is not the case.
What is also weird is that the link was working fine before moving endpoint B.
Would it be possible that a firewall between the two endpoints could block the link traffic, but still allow the link to be established? That seems to be the only difference.
-
Possible but not likely, it would have to only block the ESP traffic in one direction. Kind of an odd behavior.
