IPSec and excluding network ranges
-
I am using pfsense 2.1
I need to create and IPSec tunnel to an organization with multiple subnets (as an example let's say):
60.0.0.0/16
60.9.0.0/16I know I can do this creating multiple phase 2 entries to my tunnel and having done this I do not believe I will have problems. Unfortunately, I need to exclude part of the above subnets. So let's say:
60.0.7.0/24
60.0.9.0/24
60.9.4.0/24need to be excluded from the tunnel and routed to the WAN, not over the tunnel. How do I do this?
Regards,
- Henrik
-
AFAICT there's no way too do this with the current IPsec implementation on pfS 2.1.x. It is possible on Linux.
-
If you can create p2 entries for different networks, why can't you simply create p2 entries for the collection of networks that leaves the desired "holes" you want?
E.G., to leave the 60.0.7.0/24 "hole"
you want 60.0.0.0 - 60.0.6.255, which is
60.0.0.0/22
60.0.4.0/23
60.0.6.0/24followed by 60.0.8.0 - 60.0.8.255, which is
60.0.8.0/24and so on
…so you'd make p2 entries for
60.0.0.0/22
60.0.4.0/23
60.0.6.0/24
60.0.8.0/24and so on -- no?
-
If you can create p2 entries for different networks, why can't you simply create p2 entries for the collection of networks that leaves the desired "holes" you want?
This is my current plan, but it will be a real pain to do so, because the include/exclude subnets are more complex then my sanitized example above. The number of phase 2 entries entries I may need to define may be impracticable. I will post precise numbers when I have them (it will take some time to figure it out). Also, if there is a limit to the number phase 2 entries, then I may run up against that limit… we shall see.
-
This is my current plan, but it will be a real pain to do so, because the include/exclude subnets are more complex then my sanitized example above. The number of phase 2 entries entries I may need to define may be impracticable. I will post precise numbers when I have them (it will take some time to figure it out). Also, if there is a limit to the number phase 2 entries, then I may run up against that limit… we shall see.
I has noted the proposed solution before I even posted my question, but I hesitated due to the CIDR "math" involved (which looked time consuming). It took, however, less time than I expected to convert my "include/exclude" CIDR's to "include only" CIDR's.
I have 4 CIDR's I need to include in my VPN. Within those, I need to exclude 3 CIDR's.
I converted my include/exclude CIDR's to IP network ranges using this tool:
http://www.techzoom.net/tools/network-ip-calculator.en
In my case my include/exclude CIDR's converted into 3 contiguous IP ranges. Then I used this tool:
http://www.ipaddressguide.com/cidr#range
to convert those 3 IP address ranges to CIDR's. The end result (for me) is 23 CIDR's(!) I need to include in phase 2 of my ipSec tunnel. Assuming pfSense can do this I may have the issue resolved
If anyone knows a better tool, or alternative tool set I can use to verify/check my answer with I'd love to know it.
This should work, but –- frankly --- it is more painful then it should be. I hope the ability to exclude CIDR's will be added to pfSense (feature request!!!).
Having found an answer that will (should) work means I can continue using pfSense. I was starting to look into Juniper SRX or Cisco ASA devices... something I had really hoped to avoid.
Regards,
- Henrik -
Though IP-range to CIDR converters are available via various web pages, they're often cumbersome to use – especially if you have a lot of stuff to convert.
Here's some scripts I built for doing command-line/scripted IP range to CIDR conversions using code from pfSense (1 shell script, 2 PHP scripts and a ReadMe):
http://www.derman.com/Resources/Blogs/IPrangeToCIDRscripts.zip
If you have a large number of IP ranges to convert, put them into a text file and cat/pipe the text-file contents through the PHP script that takes entries from STDIN. I regularly process tens of thousands of entries because I use these scripts/commands inside other scripts that I use to automatically assemble block lists from various Internet sources which are daily loaded into pfSense as aliased URL Tables to support various "bad-guy" IP-blocking rules (at some point I'll put together a blog on the blocking stuff).