Policy NAT for IPSEC VPN {$250}

kapara

I need to be able to connect to multiple sites via VPN which have the same subnet. Changing the customers subnets is not an option. I know this is supposedly being worked on so hopefully this will kickstart it and get it done before I have to buy another Cisco VPN 3005 Concentrator which used is about $500. Hopefully others will jump on board to get this functionality.

1. Configured via the GUI
2. Ability to use as a VPN concentrator appliance or part of firewall.
3. Full documented directions on how to setup.
4. Directions on how to configure a VPN tunnel between pfSense 2.0 and 1.2 or 1.2.1.

kapara

Remember reading that someone was working on this….Any feedback would be appreciated as I am getting to the point of buying a Cisco or Juniper device but would rather pump that money into pfSense.

eri--

I will give it a look and give you a respone in 2/3 days.

kapara

Thanks…

kapara

My customer pulled out and bought a Cisco VPN concentrator since they could not wait. I will keep my $250 in and hope others might join in to get this feature implemented.

kapara

Unless someone else is interested I will be pulling this bounty by tomorrow.

Mark

eri--

Just for history logs.
This is doable by modifying racoon to add another configuration ip on sainfo.
For example if we want to nat everything from subnet 192.168.0.0/24 to 10.10.10.1/32 the sainfo needs to understand the policy
sainfo subnet 192.168.0.0/24 any (address 10.10.10.1 any) $remote_config
{
}

so it can find the SA one for the out direction(192.168.0.0/24) and one for the in direction(10.10.10.1/32).

Its not much work but needs to be done.
This can even be forwarded to ipsec-tools wither way for someone with C language understandings its 2-4 hours of work.

severach

To be a policy NAT the NAT must be placed on the firewall policy or policy routes to allow different traffic types to have different transformations. I'm a bit surprised that it isn't already supported waiting to be revealed by the pfSense interface. Here in the racoon config it would be a phase 2 NAT which some router vendors misrepresent as policy NAT. While policy NAT can perform more intricate transformations, phase 2 NAT is usually sufficient and simpler to implement by avoiding the router and firewall. Eventually policy NAT should also be implemented.

Before messing with the code just to produce the minimum standard I'd like to detail some of the more advanced NAT over IPSec features found in commercial routers. A small amount of extra work could produce a NAT over IPSec much better than what has been suggested here. Because industry support for NAT over IPSec is so poor each additional feature makes the router substantially more valuable.

It is unfortunate that so many routers including pfSense implement NAT over IPSec so late and so poorly or not at all. This must have feature for me is found one way or another in Juniper Netscreen, Zyxel, Fortinet Fortigate, Cisco Pix, Watchguard, and SonicWall. Non commercial routers usually do not implement NAT over IPSec at all even though the simplest implementation would be very easy.

NAT over IPSec is used to solve address conflicts when both peers use the same subnet and cannot be changed. It is used when the other peer administration specifies that a particular subnet which is often public must be used and their hardware is not good enough that they can do it themselves. It is used when local addressing must be changed but the old addressing must be emulated for VPN peers.

No router at any price has a full implementation which is policy and phase 2 NAT over IPSec on source and destination with many to few/one, inbound NAT, and inbound DNAT. pfSense would eliminate a major reason it gets passed over for commercial routers with a good implemenation of NAT over IPSec.

Until pfSense gains NAT over IPSec people stuck with overlapping subnets, must NAT old addresses to new, or must NAT to public IPs need immediate solutions. Because NAT over IPSec is so poorly supported in currently available routers and the implementations often have hidden flaws, it is a challenge to find a router that supports what you need and can grow with you in the future. To help everyone else avoid routers that are unsuitable and to avoid some pitfalls swapping back and forth between different brands I will post what I know about the brands I have. When implemented the flaws found in other brands should be checked in pfSense to ensure they work properly.

Cisco Pix v6.3.5. Policy NAT on source IP by address. The static route only NATs a single address at a time and affects non tunnel communication so if the IP must communicate over the Internet an owned and unique public IP must be used. Policy NAT are hard to create and maintain because the settings are disparate. Mappings apply to all tunnels and there seems to be no control over which tunnels get translated. GUI is Java based and often requires old versions of Java. The GUI doesn't always create functional tunnels. DHCP reserved addresses are not supported. No GUI and good live CLI based tunnel failure information. Poor GUI tunnel monitoring and control. Router management of tunnels is automatic. Firewall control of tunnels is manual with some assistance from a wizard.

Fortigate 3.00-b0744(MR7 Patch 6): Multiple methods to outbound NAT on source IP by subnet on firewall policy. Outbound NAT with a numerical shift is partially supported. Outbound NAT can only be set through the FortiOS CLI. Outbound NAT maps to all subnets without interfering with routing. Inbound NAT is available to help solve routing issues. Tunnel policy can be specified as a subnet or an address range. Maximum preshare key length is 127. DHCP reserved addresses must be inside an active DHCP range. No GUI and good live CLI based tunnel failure information. Excellent GUI tunnel monitoring and control. Firewall and router management of tunnels is manually controlled. IKE connection bugs make the tunnels unreliable without DPD.

Juniper Netscreen ScreenOS 5.4.0r13.0: Multiple MIP on source IP by subnet. MIP maps to any subnet that does not include the untrust ip. Trust to trust mappings can be entered but do not function. This limits mapping to public IPs and does not allow mapping from old IPs to new. Because the MIP address does not exist on the local network these conflicts should not occur therefore MIP is implemented incorrectly on the Netscreen for tunnels. Settings to manage Policy NAT and tunnels are hard to maintain because they are pretty disparate and the GUI requires tunnels to be manually destroyed and rebuilt to make simple changes. Inbound NAT is available but not tested. GUI is Java assisted for Firefox. Maximum preshared key length is 127 though the GUI accepts 184. Preshared key must not contain double-quote (") character. Phase 2 Lifetime KBytes isn't large enough for standard values. DHCP reserved addresses must be outside all DHCP ranges. Excellent logged GUI and excellent logged CLI based tunnel failure information. Good GUI tunnel monitoring and control. Firewall and router management of tunnels is manually controlled with some assistance from a wizard.

Zywall 5/35/70 UTM 35_4.04(WZ.5)C0. Phase 2 Virtual Address Mapping on source IP by address range which allows for a numerical shift. Virtual Address Mapping across a wan IP of the Zywall blocks NAT and Internet access to that interface and the tunnel policy cannot be defined separately to avoid this. Because the Virtual Address does not exist on the local network this routing interference should not occur therefore Virtual Address Mapping is implemented incorrectly in Zynos. Tunnel policy can be specified as a subnet or an address range. Maximum pre-shared key length is 31. Limited CLI and no CLI compatible config export. Does not support phase 2 lifetime KBytes. DHCP reserved addresses can be inside or outside DHCP ranges. Good logged GUI and no CLI based tunnel failure information. Excellent GUI tunnel monitoring and control. Firewall and router management of tunnels is completely automated and invisible.

Zywall USG 100_2.12(AQQ.1)C0: Phase 2 Inbound/Outbound traffic NAT does not work at this time for anything other than simple and trivial cases because the firmware implementation is incomplete. Inbound/Outbound traffic NAT on both source and destination by subnet or address range which allows for a numerical shift. Inbound DNAT is available. Tunnel policy can be specified as a subnet or an address range. Maximum preshared key length is 32. Does not support Phase 2 Lifetime KBytes. DHCP reserved addresses can be inside or outside DHCP ranges. Good logged GUI and no CLI based tunnel failure information. Excellent GUI tunnel monitoring and control. Firewall and router management of tunnels can be completely automated or manually controlled.

Sonicwall Pro 2040 SonicOS Enhanced 4.0.0.1-49e: Phase 2 policy NAT on source and destination address by subnet or address range which allows for a numerical shift. Policy NAT to all subnets without interfering with routing. Tunnel policy can be specified as a subnet or an address range. Maximum preshared key length is 128. Preshared key must not contain double-quote (") character. Does not support Phase 2 Lifetime KBytes. No CLI compatible config export. DHCP reserved addresses must be outside all active DHCP ranges. Perfect logged GUI and logged CLI tunnel failure information. Fair GUI tunnel monitoring and control. Set up of multiple phase 2 under a phase 1 is more cumbersome than with other routers. Multiple phase 2 under a phase 1 may not share the same remote address. Firewall and router management of tunnels is completely automated.

Cisco VPN 3005 Concentrator vpn3005-4.7.2.P: Does not support static IP to dynamic IP address. Not intended for use as a NAT router. Intended for use only with static IP service. Non communicative UI. Testing halted because unsuitable for purpose. Appears to have LAN-to-LAN NAT rules for 1-to-1 policy NAT, address pooling, and inbound PAT for source address.

Other brands including Draytek, McAfee, Symantec, Watchguard, Check Point, HotBrick, Nortel, Instagate, 3Com, Astaro, Stonegate, and many other low cost brands are not considered for some of the following reasons:

No low cost models with sufficient policies, tunnels, and sessions.
VPN performance too low for any purpose.
Terms of service too strict.
Documentation clearly indicates there is no NAT over IPSec in any form or unable to find documentation.
Market too narrow or specialized.
No longer supported.
Computer based, not an appliance.

Some of the tested routers suffer from these same problems but I was able to get some to test.

Conclusion:

So long as you NAT only to private IPs or administer both peers many of these routers will work. To interop with my peers with inflexible requirements I need to map to my wan IP subnet, map some old hosts to new within the same subnet, and have many phase 2 under phase 1. Fortigate is the only brand so far that can run all of my tunnels. Fortigate has the best firewall which does the most work in the least number of policies while allowing good observation and control. Fortigate has the best GUI and an excellent CLI. Fortigate is good hardware with generous sessions, policies, tunnels, and SSL users. Unfortunately FortiOS has an IKE connection bug that makes tunnels unreliable so I get weekly tunnel failures and Fortinet TAC is not willing to fix the issue. Fortigate does not NAT the destination address so it isn't suitable for use long term. The Zyxel USG series looks like it will be the best long term solution.

Eugene

I am not sure my requirement falls in here..
my LAN–-192.168.8.0/24 pfSense 1.1.1.1/24------------2.2.2.2/24 FW 198.x.x.0/24---remote LAN
I am asked to create Ipsec tunnel between 'my LAN' and 'remote LAN' but these remote guys say that they can not accept local 192.168.8.0/24 net, they need public 172.20.2.0/24.

Is it possible to make this NAT happen at pfSense:

when packet comes to LAN interface destined to 198.x.x.0/24 the source IP 192.168.8.x to be modified to 172.20.2.x and forwarded to this tunnel.
when traffic comes from the tunnel destined to 172.20.2.x its destination IP to be modified to 192.168.8.x

TCP traffic will be initiated only from 'my LAN'.

If this bounty about the scenario described above I'll put $200.

severach

All posts indicate that pfSense cannot currently NAT VPN to a public IP. The phase 2 NAT for the source address suggested by ermal will do what you want which uses the features of your router to meet your peer's addressing requirements. If that seems backwards, it is since whatever it is they want you must administer which is necessary so long as first rate vendors insist on providing second rate products. It would be much better if the needs and the administration were at the same peer.

If your peer had phase 2 or policy NAT for the destination address they could handle their own needs without putting any restrictions on you and allow you to choose a low cost router that didn't have policy NAT. They are asking so their top brand router probably doesn't have it. Phase 2 NAT for source and destination are equally easy to implement so there's no good excuse for routers to implement one without the other. The presence of phase 2 NAT for both the source and destination would place pfSense among the best. Implementing all the features I've suggested including both phase 2 and policy NAT would make pfSense unbeatable at any price and would hopefully get the other vendors to get it right or get out.

172.20 isn't a public address but you probably used that as an example to avoid exposing your public subnet.

I have the same problem as you. A VPN router that can't at least phase 2 NAT is of no use to me and the reason I must buy way too much router for my network is the size of some other network. My peer's network is so large that they require all VPN to traverse with public IP addresses to minimize router quagmire. The necessary policies are always maintained to route public IP to the VPN peer. They have enough trouble routing random subnets around their own network without causing occasional VPN outages from inadvertent routing errors for the random subnets that must route to the VPN peer. Their customers like me must make up for the incomplete policy NAT implementation in their top brand router by buying our own top brand router since pfSense can't do it and low cost VPN routers refuse to implement even the trivial forms of phase 2 NAT.

I started with Cisco Pix v6.x which is definitely making money prolonging the problem. The lousy policy NAT implementation is tied to communication to the Internet which obfuscates how policy NAT works and creates unnecessary restrictions. It wasn't until I used policy NAT on the Fortigate where it is implemented correctly that I understood how simple policy NAT was and how the bad Cisco implementation had me hogtied.

Until you see how simple policy NAT is, it is difficult to match examples to your situation. NAT to a public subnet sounds different than a NAT to a private subnet so when you read the FortiOS Outbound NAT Examples it sounds like outbound NAT won't cover NAT to public IP though it does. The Pix policy NAT via static NAT adds to the confusion because Internet traffic is bound to the same address as the policy NAT so it seems like only public IP you are assigned will work and you need to buy IP addresses for each machine that communicates over a VPN. A good policy NAT implementation allows any arbitrary subnet to pass through the VPN without affecting the address used for the rest of the network, the Internet, and other VPN. Phase 2 NAT allows different addresses for different tunnels and policy NAT allows different addresses for different traffic should you ever need such maddening control over VPN NAT addressing.

The only communication to the NAT address occurs inside your peer's network which is the entire reason for their choice and why they want you to spring for a router than can provide what theirs can't. The ping to 172.20.1.1 travels through your peer's many routers until it hits the VPN peer where the address hides under the encryption and the packet goes out with the peer's own address to your VPN router. When the packet arrives the 172.20 address will disappear as your router NATs it to an address that your network will route. Return packets pass through the NAT process in reverse. VPN packets will not arrive at the NAT address they are sent to. The address disappears during transit. Packets arrive from a NAT address they were not sent from. The NAT address appears on packets during transit.

When a packet is inside either LAN the original and NAT IP addresses have meaning. When the packet hits a peer they are transported over the Internet using the peer addresses so the original and NAT ip addresses cease to have meaning until they pop out the other peer. It makes no difference whether the NAT IP is public or private since the Internet never sees communication from or to it. With a full implementation of policy NAT you don't care what subnet is. It is just numbers hidden inside the router. Let your peer choose the subnet if they want to. The subnet can be different for each peer. Public subnets you use do not need to be assigned to you. When you change ISP you can continue to use the old public subnet even though you are no longer assigned to it. You can provide as many public IP VPN targets as you need without having to buy a large static IP block and expand as needs increase. Even a single dynamic IP is sufficient.