Hi everyone, I'm currently trying to solve a simple problem for a customer, which is turning out to be more difficult than I thought (at least, on pfSense).
For the record, I've read https://forum.pfsense.org/index.php?topic=58140.0, but that doesn't solve the issue. Summary: {internet}..... [remote]---- 11.22.33.0/27 : : [pfSense 2.2] (statics pointing to .11 for 192.168.103.0 & 10.1.0.0/21) | .10 | -------+------- 192.168.1.0/24 (data center backbone) | .11 [PE router] : : [CPE] | ---+---+------- 192.168.103.0/24 (customer's main office) | [router] : 10.1.0.0/21 (customer remote offices) Summary: - customer @ 192.168.103.0/24 wants to talk to 11.22.33.0 - VPN between pfsense 2.1 (now 2.2) and "remote" (probably Cisco) is up and running in no time - customer realizes they also want their remote offices (10.1.0.0/21 spread over several sites) to talk to 11.22.33.0 * Plan A: At this point, the sane thing would be to just add 10.1.0.0/21 as an additional Phase 2 scope to the tunnel between pfSense and "remote". But it's ia painful (read: slow) process to get the paperwork done and get the other side to change things. * Plan B: My suggestion to customer: NAT on their CPE so they hide 10.1.0.0/21 behind an IP from 192.168.103.0/24, but they don't want to do that. * Plan C: Last resort - nat on pfSense before IPsec using a second Phase 2 def. Now, I know that according to the above link, I should be able to add a second Phase 2 scope for 10.1.0.0/21, mapped to 192.168.103.123/32 (an IP in the customer's net). This is aliases to localhost via a VIP. Let's remember for a second that 192.168.103.0 is *not* directly connected to the pfSense, but 2 hops away via 192.168.1.11. Anyway, I tried the above, set up the second phase 2 scope with the above mapping. It doesn't work - or rather, it only works IF traffic from 10.1.0.0/21 hits the VPN while there are no SAs yet (i.e.: if it comes first). In that case, then traffic from 192.168.103.0/24 and 10.1.0.0/21 makes it through (at least in the direction customer -> 11.22.33.0/27). If the traffic from 192.168.103.0/24 hits the VPN first, then that works, but it just drops traffic from 10.1.0.0/21. I haven't debugged this *yet*, as I need a working solution now. I looked at the console, and can see that there's a NAT rule set up on enc0, and, as stated before, it works if traffic from 10.1.0.0/21 is seen first. * Plan D: ok, let's do manual "outbound" NAT on the inside IF - NAT is disabled on this box (it's a VPN concentrator exclusively), so I create the following rule: NAT, inside interface, source 10.1.0.0/21, destination 11.22.33.0/27, NAT to: interface address (VIP alias) - 192.168.103.123/32 Well, that doesn't work either. Now, I've been using FreeBSD for 20ish years, and in the past, I have (and still) solve this kind of problem as follows: # ipfw add 10 divert natd ip from 192.168.103.0/24 to 11.22.33.0/27 via $int_if # natd -reverse -n 192.168.103.123 ... and traffic gets natted to IP 192.168.103.123 as it enters the system via $int_if (thus, -reverse), before it gets processed by IPsec. Then, I'd create a tunnel with an SP for 192.168.103.123/24 <-> 11.22.33.0/27. Except it doesn't seem to be possible to do this with pfSense. Either that, or I'm dense (or plan C should work). So here I am - any good suggestions ? I'd rather avoid having to hack something from the command line - I like to be able to upgrade smoothly without local kludges. PS: IP addresses have been changed to protect the innocent. No animals have been harmed, pigeons or otherwise. Yes, this has been tested with both 2.1 and 2.2 - same issue. _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
