2.1.5 to 2.2 upgrade, problem due to IPsec Ph2 entries?



  • I tried to upgrade from 2.1.5 to 2.2 in the wee hours this morning, didn't go well.  Couldn't get serial on box at first after upgrade (I have an ethernet serial server attached to it so I can telnet to it); had to direct cable.  got a prompt then, but didn't have normal console menu, just a #.  typed "reboot" and it seemed to boot OK, got normal console menu.

    HOWEVER

    Could not ping LAN IP of the box.  :o  Could not SSH or get webmin to load, even after using console "reset LAN ip" option on a hunch.

    I suspect this may be related to the ipsec daemon changes and my specific ipsec tunnels.

    I have a broad ipsec phase2 entry for my company (192.168.0.0/16), but I also use a /24 out of that block for my home LAN (simplifies a lot of firewall stuff for me to do remote work).  I think that whenever I was trying to get traffic to/from my home LAN block (192.168.42.0/24) it was trying to re-route over ipsec, but I have no real way to confirm that.

    Didn't know how to disable ipsec from serial console, so I rebooted and reverted to second 2.1.5 slice (yay nanobsd!)

    Raccoon has zero problems with this setup, the more specific subnet (my LAN) stays local, and anything else for 192.168.0.0/16 goes to the tunnel.

    Is this not possible with StrongSWAN, or should I just nuke and reconfig the whole thing and that will make it work?  If I disable IPSec before upgrading, will it still be off afterwards (so I won't be locked out again)?

    Can Strongswan do an actual "route based" (cisco style, each endpoint has an IP and traffic is routed between them without explicit Ph2 entries) VPN instead of individual subnet ph2 entries? That will make my life even easier (I can run BGP or OSPF or even RIP across the tunnel and get the specific /24s I want instead of having to clobber the entire /16, makes cable modem management mildly annoying ;) ).  My remote endpoint is a Palo Alto which can handle this, but I know Raccoon did not.

    The console should probably have a "disable/enable ipsec tunnels" option, or maybe a sub-option in the LAN IP re-assignment to drop them when you reset things…

    As an aside - I know I probably should've taken a full config backup before the upgrade, but why doesn't the installer do that for me?  After reverting to the other slice, I get warnings about my config being from a newer version, and I have no other recent backups.  My own damn fault, but most other systems either WARN you to make a backup, or silently make one for you.  I'd be fine with it clobbering any other previous upgrade-backups, but it seems like it would be a pretty easy and logical thing to do, no?



  • It was definitely the "broad" and overlapping ipsec ph2 entry that caused the problem.  Disabled IPSec and upgrade went fine.  This is a behavior change from raccoon.

    Would love to know if it's possible to do a route-based VPN with strongswan, but can't find much/any documentation on how to make it work (if even possible).  I'm guessing I would need to make a (private) loopback address on pfSense, but I don't know if that can then be used to pass traffic from the LAN via ipsec to the remote side.

    I just had to add ~12 phase2 entries to fix this (admittedly, slightly more than I needed so I could also de-agg 192.168.100.0 and still be able to access my cable modem at home).  :P  route-based would be so much nicer, especially since I only need ~40-50 individual /24s out of the /16 right now.



  • I'm currently experiencing the same problem, due to the overlapping of the local and remote IPSec sub-nets. By using the console port with a serial cable to my Netgate box I can use "ipsec stop" at a shell prompt to turn off the IPSec service, and restore the web interface. Currently planing to downgrade to 2.1.5 until this is fixed. It would be a nightmare to maintain that many phase 2 entries.



  • @avispa:

    I'm currently experiencing the same problem, due to the overlapping of the local and remote IPSec sub-nets. By using the console port with a serial cable to my Netgate box I can use "ipsec stop" at a shell prompt to turn off the IPSec service, and restore the web interface. Currently planing to downgrade to 2.1.5 until this is fixed. It would be a nightmare to maintain that many phase 2 entries.

    Well, assuming your remote side is a /16 and you have a single /24 out of that, you can probably split it into fewer ph2 entries than I did.  I needed 12 because I took out two non-contiguous /24s, both my LAN subnet and 192.168.100.x (again, for cable modem admin page access).

    This setup allows me to access multiple different MPLS sites (all /24s out of the same /16) in my company from home.

    As an example, if your home LAN was 192.168.99.x/24, but you want to have the rest of 192.168.0.0/16 accessible via VPN, you could deagg to:
    192.168.0.0/18
    192.168.64.0/19
    192.168.96.0/23
    192.168.98.0/24
    (your LAN subnet would be here)
    192.168.100.0/22
    192.168.104.0/21
    192.168.112.0/20
    192.168.128.0/17

    That's only 8 ph2 entries, which is still a pain, but not completely unmanageable.  You would end up sending traffic down the tunnel that you may not have a remote subnet for (that's how my setup works, currently we are only up to ~192.168.156.0/24 or so), but this isn't the end of the world…  It's why I would prefer to do a routed setup using a routing protocol instead though.

    "ipcalc" (it's a perl script) is a useful tool to deagg networks like this.



  • That is a behavior change as we no longer exclude the LAN/other interface IP automatically as we did in 2.1x. Didn't seem it was all that useful, but yeah a couple scenarios like this have come up. We'll bring back a means of accommodating this, either by adding the ability to negate your P2s, or bringing back 2.1x and earlier automatic exclusion of the system's own IP on that interface.



  • @cmb:

    That is a behavior change as we no longer exclude the LAN/other interface IP automatically as we did in 2.1x. Didn't seem it was all that useful, but yeah a couple scenarios like this have come up. We'll bring back a means of accommodating this, either by adding the ability to negate your P2s, or bringing back 2.1x and earlier automatic exclusion of the system's own IP on that interface.

    Appreciate the reply Chris.  I believe in strongswan there is something called a "shunt" which would accommodate this sort of thing as well?

    I would love to see something analogous to Cisco's "VTI" and Juniper's "ST" interfaces for VPN; most major firewall vendors have something similar to this, even "weird" stuff like Palo Alto support this (and PA doesn't do IPsec+GRE so I have no other way to replicate it against pfSense).



  • @bradenmcg:

    I believe in strongswan there is something called a "shunt" which would accommodate this sort of thing as well?

    Yep, that's what I was referring to re: adding the ability to do negation.

    @bradenmcg:

    I would love to see something analogous to Cisco's "VTI" and Juniper's "ST" interfaces for VPN; most major firewall vendors have something similar to this, even "weird" stuff like Palo Alto support this (and PA doesn't do IPsec+GRE so I have no other way to replicate it against pfSense).

    I would like to see that. It'd require a good deal of work, as there are missing pieces in underlying bits. Not on the near future road map at least.



  • @cmb:

    @bradenmcg:

    I would love to see something analogous to Cisco's "VTI" and Juniper's "ST" interfaces for VPN; most major firewall vendors have something similar to this, even "weird" stuff like Palo Alto support this (and PA doesn't do IPsec+GRE so I have no other way to replicate it against pfSense).

    I would like to see that. It'd require a good deal of work, as there are missing pieces in underlying bits. Not on the near future road map at least.

    That's what I've been reading, apparently neither BSD or Linux have the correct tunnel interface existing on the OS, making this more complicated.  That said, Ubiquiti has VTI in their gear, so it can't be too bad to do… I believe they are some form of *nix underneath, wonder if the source for this is open?

    I may have to grab an EdgeRouter and stick it behind my pfSense box just for VPN purposes.  (I'm not likely to ever ditch pfSense at the edge, unless someone else starts supporting UPnP/NAT-PMP, since I have game systems.)