NAT before IPsec VPN on pfsense 2.1
-
Hi,
I am a new pfsense user. I try to replace an old setup with some commercial firewalls and VPN boxes with a single fsense box. For now, everything is running great except NAT before IPsec VPN connections.
I really need to have NAT occuring before IPsec, that is sadly not something i could change.
As it is not supported on pfsense 2.0, I ended up with 2.1-BETA1 (built on Wed Jan 23 05:01:39 EST 2013), where until now the upgrade ran smoothly.
The new checkbox is great, but it's signification is not very clear to me:
"In case you need NAT/BINAT on this network specify the address to be translated."
Let's say, I have:
- real LAN is on OPT1, with network: 10.0.0.0/24
- "LAN" interface is only used for IPsec phase 2 which needs to be in 192.168.3.1/24
- firewall on the other endpoint only accepts connections from 192.168.3.1
IPsec phase 2 is configured as such:
- Local Network Type: LAN subnet (that is 192.168.3.1/24)
- In case you need NAT/BINAT on this network specify the address to be translated: Type: address 192.168.3.1
Without the NAT configured, the IPsec VPN is running fine and can ba accessed from the 192.168.3.1/24 network as expected, but not from 10.0.0.0/24 as NAT is not done.
With the NAT configured as described before, IPsec doesn't even start.
What am I doing wrong ?
Do you have some idea, please ?
-
Leave alone the LAN subnet and create another phase2 entry for the 10.xxx subnet and there put the nat checkbox with the to be natted address.
That's the way it needs to be configured. -
it seems i need to define 10.0.0.0/24 explicitely, as if i choose "OPT1 subnet", then in the IPsec status page, the start/stop button won't appear. Is it the expected behavior ?
-
hmmm, phase 2 is failing
Jan 26 13:38:28 racoon: ERROR: failed to get sainfo.
I have defined:
Local Network : 10.0.0.0/24
NAT for local network: 192.168.3.1/24 (that is: the local networked i should use for phase2for the other endpoint)
Did i still misunderstood how it should be configured ?
Or do i need to remove the 192.168.3.1/24 real interface, that has become useless ?
-
Thanks, i am now one step further:
Now i have done following:
-
suppress local interface with phase 2 subnet
-
LAN is 10.0.0.0/24
-
IPsec phase 2 local subnet is 10.0.0.0/24
-
IPsec phase 2 NAT is 192.168.3.1/24 (the subnet required on phase2)
On the status page, the IPsec connection is reported as down.
But it seems it is up: I can ping some host on the remote side, ssh to it (but connection hangs after a few seconds)
I tried to decrease "System: Advanced: Miscellaneous: Enable MSS clamping on VPN traffic" to 1300, as it fixed same symptoms before, but it doesn't fix this time… Strange. I must be missing some point again.
-
-
Well what you actually want is a 192.168.3.1/32 since you only say that address is allowed.
Otherwise it generates a binat rule which might not be what you expect. -
Thanks for your help, very appréciated ! Help on IRC was also usefull !
I created a phase 2 with my LAN subnet (10.0.0.0/24) and NAT as 192.168.3.1/32 and it's working correctly for one of the two tunnels.
For the second tunnel, i can for example ssh to a server, but connection gets rapidly dropped. For the same symptoms on 2.0, I had to adjust MSS clamping to remote MTU (1420) - 40, that is 1380. This time this doesn't solve the connection issue.
-
You have 2 tunnels with the same phase2?
That's a bit….Without posting more detail i cannot help you.
-
I have 2 different phase1: "A" and "B".
Each phase 1 has one unique phase2, each one is with subnet 192.168.3.1/24 on my side.
For first remote (phase 1 "A"), their firewall only accepts traffic from 192.168.3.1, therefore i need to NAT before IPsec.
I configured the phase 2 with my LAN subnet as subnet, and the single address 192.168.3.1 as NAT.
It is working fine now: traffic passes, i can ssh to the hosts, browse the webservers out there from my LAN. Problem solved. Yepee.For the second remote (phase 1 "B"), traffic from the whole subnet 192.168.3.1/24 is accepted, but not traffic from my LAN (10.0.0.0/24), therefore i also need to NAT befor IPsec.
I configured the phase 2 with my LAN subnet as subnet, and the subnet 192.168.3.1/24 as NAT.
From LAN I can ping some host on the other side, ssh into it, but connection hangs if i run, for example, top. Traffic from monitoring agents is ok. When connection hangs, i get lots of blocked traffic in the firewall log, but the firewall is fully open.
With pfsense 2.0, i had the same symptom: connection hanging, and it was fixed by fixing MSS clamping to 1380 (MTU of remote peer is 1420).
This time, it doesn't help.Which other details could be usefull to you ?
Do you need the logs from ipsec ? some logs from firewall ? some packet capture log ?
-
Put ipsec in verbose mode and give me that.
-
here it is: hope 150 last lines is enough ?
-
that's more complete: full log from racoon restart, until i get a connection, ssh into a host, and get blocked.
-
hum, it seems it has been truncated. In the log after the restart you can see things happning for both ipsec tunnels. tunnel "A" is not green in the status interface, but it is usable. tunnel "B" is just half-working.
-
On the next snapshot the status page should be fixed.
For the second tunnel can you show me the /tmp/rules.debug file by anonimizing the ips?
I am saying this since the nat rules for the same subnet are generated and your first tunnel rule might be impacting your second one.I removed previous dump of you since your private keys are pasted in there and your ips as well :)
-
Thank you for the ruleset and information.
It seems that mss clamping was a bit broken for ipsec on 2.1, please try with the next coming snapshot or gitsync it should behave better. -
Thanks a lot !
Sorry for the last question: When will the next coming snapshot published ?
-
It takes around 8 hours usually but it sometimes is a bit faster.
For you gitsync should be easier, check one of the sticky topics on it.The related change is this https://github.com/bsdperimeter/pfsense/commit/af982472816c43827177e499011b92531ba40d72
-
gitsync worked like a charm, issue is fixed, many many many thanks !
-
I had the same problem on 2.0.2, so I was using an additional NIC just for having a correct local subnet for IPSec.. I guess I could've tried replacing the bogus NIC with a Virtual IP on the LAN subnet..
Anyway, I just crossed fingers and upgraded to 2.1-BETA1 (i386) built on Thu Jan 31 12:38:17 EST 2013 then I followed your steps.
Now I have:
-
in Advanced > Miscellaneous checked Enable MSS clamping on VPN traffic and set it to 1200
-
IPSec Phase 1 setup correctly
- IPSec Phase 2 with
Local Network 192.168.111.0/24 (real LAN)
NAT/BINAT single address 192.168.36.129 (from remotely imposed 192.168.36.129/24 subnet)
Remote subnet 192.168.36.0/25
- IPSec Phase 2 with
and got phase 2 with NAT working… "Yippee ki-yay, mf!"
One last glitch that bugs me: the Status > IPSec page still shows the tunnel as down ???, even though log says
INFO: ISAKMP-SA established
and
INFO: IPsec-SA established
, and traffic gets through normally…
Can this log message be relevant
racoon: NOTIFY: no in-bound policy found: 192.168.36.0/25[0] 192.168.111.0/24[0] proto=any dir=in
?
I already have a Firewall rule on the IPsec interface that allows all traffic through.
Did I miss anything or is this issue still on the devs' radar ?
Now if only version 2.1 had a PPTP helper, allowing multiple distinct outbound GRE sessions to the same remote IP, I'd be the happiest pfSense user of all time! ::)
-
-
One last glitch that bugs me: the Status > IPSec page still shows the tunnel as down ???, even though log says
INFO: ISAKMP-SA established
and
INFO: IPsec-SA established
, and traffic gets through normally…
I pushed a fix for this but will double check.
Can this log message be relevant
racoon: NOTIFY: no in-bound policy found: 192.168.36.0/25[0] 192.168.111.0/24[0] proto=any dir=in
?
No worries about it. Maybe need to remove the warning completely but its because you are natting that the warning shows up.
Now if only version 2.1 had a PPTP helper, allowing multiple distinct outbound GRE sessions to the same remote IP, I'd be the happiest pfSense user of all time! ::)
I am not sure for 2.1 it will make it :)