Outbound IPSec traffic using wrong ph2 tunnel
-
2.2-RC (i386)
built on Fri Jan 02 14:57:04 CST 2015I have two overlapping subnets, using the same ph1:
- Loc: 192.168.101.37/32 Rem: 10.10.12.33/32
- Loc: 0.0.0.0/0 Rem:10.10.12.32/28
DHCP requests is sent from 10.10.12.33 to 192.168.101.37 through the first tunnel, but the response is sent through the other tunnel, causing the remote peer to drop the package.
In the IPSec configuration, I have placed 10.10.12.33/32 above 10.10.12.33/28, assuming 10.10.12.33/32 will have a higher priority.
In 2.1.5 it sometimes work, depending on which ph2 tunnel is first established.
11:03:40.634818 IP 10.10.12.33.67 > 192.168.101.37.67: UDP, length 250
11:03:41.636614 IP 192.168.101.37.67 > 10.10.12.33.67: UDP, length 300
11:03:43.551720 IP 10.10.12.33.67 > 192.168.101.37.67: UDP, length 250
11:03:43.552431 IP 192.168.101.37.67 > 10.10.12.33.67: UDP, length 300
11:03:46.570757 IP 10.10.12.33.67 > 192.168.101.37.67: UDP, length 250
11:03:46.571096 IP 192.168.101.37.67 > 10.10.12.33.67: UDP, length 300
-
Reporting IPSec issues with 7+ days old snapshots is totally useless. Kindly read the commit activity.
https://redmine.pfsense.org/projects/pfsense/activity
-
Thanks for the reply.
I am following the redmine activity, if not hourly, at least daily. I did try the latest snapshot last night, but due to other issues with IPSec that I will report shortly (traffic using wrong tunnel in general), I had to fallback to a somewhat stable IPSec release.
By looking at redmine, I have a hard time identifying any commits the last few days which resolves the issue reported in this thread.Please bear in mind that what I am trying to achieve have never worked properly with pfSense, but I hoped it was doable in 2.2 as it is possible to arrange the ph2 config in a specific order. Why would we else arrange ph2 is specific orders?
-
Can you show the output on the status->ipsec SPD screen?
Normally it should show the priority of checking and the first one wins.
My only concern is that the dhcp reply is coming back with not the same src as the dst of request hence going though the other tunnel.
-
Thanks Ermal!
Looking at the trace I did, src address is correct:
11:03:40.634818 IP 10.10.12.33.67 > 192.168.101.37.67: UDP, length 250
11:03:41.636614 IP 192.168.101.37.67 > 10.10.12.33.67: UDP, length 300
11:03:43.551720 IP 10.10.12.33.67 > 192.168.101.37.67: UDP, length 250
11:03:43.552431 IP 192.168.101.37.67 > 10.10.12.33.67: UDP, length 300
11:03:46.570757 IP 10.10.12.33.67 > 192.168.101.37.67: UDP, length 250
11:03:46.571096 IP 192.168.101.37.67 > 10.10.12.33.67: UDP, length 300Edit:
And you are right, 10.10.12.32/28 is the first entry in SPD.Edit2:
Actually, the SPD order keeps changing. Imediately after IPSec startup, the order is according to the config, but after the different tunnels are being established, the order is changed.
-
if IPSec -> SPD determins the processing order of ipsec packets, is it possible to have the order fixed according to the ph2 configuration?
-
Normally that is a FreeBSD property of how it manages these rules.
Whenever they get updated they get put last IIRC.There is a priority setting supported on strongswan for such situations but FreeBSD does not support it.
Though apart technical details you solution is to remove the second phase2 and use firewall rules to control this.
It is more manageable as well like that, no?