Routed IPsec using FreeBSD if_ipsec(4) VTI
Add routed IPsec using
if_ipsec(4) VTI (Virtual Tunnel Interfaces) from FreeBSD 11.1 and later with strongSwan.
- Add code to create and manage the interfaces like other interfaces (can assign, setup static routes, specific rules, packet capture, NAT, etc)
- Add a new Phase2 mode for VTI which defines the local and remote ipsec interface endpoints (like gif or tun)
- Add input validation to restrict usage of VTI to supported cases
To me, I have a patch to commit.
Please welcome routed IPsec using if_ipsec VTI interfaces. Implements #8544
To use, create a P1/P2 and set P2 to VTI using local/remote network as tunnel endpoint addresses, then assign the interface (enable, but IP type = none), and use like any other interface for routing.
Add vpn.inc changes for IPsec VTI that missed the previous commit. Ticket #8544
Rework how IPsec VTI interfaces and reqid specifications for same are formed. Ticket #8544
#3 Updated by Michael OBrien 12 months ago
Jim Pingle wrote:
Just tested with 6/2 9:59:05 CDT snapshot - I'm not sure I 100% understand the instructions, but I did the following on each side:
Once a new snapshot is up with the later two commits it should be OK for testing.
- Added P1 IKEV2 with the usual config I'd use for a transport P2 that I was throwing GREs over
- Added P2, set local network as 192.168.240.1, remote 192.168.240.2 on partner 1, reversed on partner 2
- Assigned OPT interfaces to the new ipsecX int on both sides, enabled but did nothing else in config (like OpenVPN)
- Created allow-all firewall rules on each OPT interface for testing
IPSec status shows P1 up, but no traffic over P2 (out or in).
Both gateways show down, and when I try to ping from each box to the other on the 192.168.240 addresses, I get "ping: sendto: Network is down".
Route table looks right (not trying to do any "real" routing yet):
192.168.240.1 link#9 UHS lo0
192.168.240.2 link#9 UH ipsec1
Interfaces are odd, they show netmask of /24... When I tested with 10.200.0.1/2 addresses, the interfaces both showed netmasks of /8. I suspect it should be a /30, but the netmask was greyed out in P2 so I'm not sure how this gets set.
tcpdump doesn't show any traffic on either interface.
Let me know if you'd like further testing or info!
#4 Updated by Jim Pingle 12 months ago
- Status changed from Feedback to Assigned
Reopening as there are some issues with how the tunnel addresses are applied to the interface (local and remote should be in the same subnet, but it may work with both sides as address or /32 as well.
Also interface changes are not applied when IPsec changes are applied, only when the interface itself is saved/applied which is counterintuitive. Should be easy to fix that while I'm at it.
#6 Updated by Jim Pingle 12 months ago
- Status changed from Feedback to Assigned
There is a problem with how the interfaces are numbered, since with more tunnels and phase 2 entries around the ID used for the interface does not match the reqid needed to properly hook into the P2, so some changes are needed in how the interfaces are determined.
#7 Updated by Jim Pingle 12 months ago
Interface numbering is fixed, VTI reqids work as expected and line up between strongswan and ipsecX numbering and uses, and I can pass traffic over interfaces that did not work previously.
The gateways are not being generated properly, and the interface address is not being added to the tonatsubnets macro, so there is still some work to do.
#10 Updated by Aidan Mountford 11 months ago
Similar to Michael Obrien, I tested this on snapshot from 1st of July.
192.168.90.1/30 (Junos) to 192.168.90.2(pfsense).
TCPDUMP on freebsd reports packets from junos being received in good order.
Ping from the pfsense box toward juniper reports "Network is Down"
IKEv2 (P1) is Up. ESP (P2) is up
Configuration is a described (tunnel endpoints in IPSEC P2 config, interface ipsec2000 configured end up with no address associated)
Any assistance I can provide in helping resolve this, please shout and thanks for providing a much needed feature!
ipsec2000: flags=8111<UP,POINTOPOINT,PROMISC,MULTICAST> metric 0 mtu 1400
inet6 fe80::1c1c:e745:6b76:4db8%ipsec2000 prefixlen 64 tentative scopeid 0x8
inet 192.168.90.2 --> 192.168.90.1 netmask 0xfffffffc
192.168.90.1 link#8 UH ipsec200
192.168.90.2 link#8 UHS lo0
Traffic on ecn0 from remote side (bgp opens):
07:48:57.313859 (authentic,confidential): SPI 0xc92d0d56: IP 192.168.90.1.57271 > 192.168.90.2.179: Flags [S], seq 3717540734, win 16384, options [mss 9152,sackOK,eol], length 0
07:49:00.514212 (authentic,confidential): SPI 0xc92d0d56: IP 192.168.90.1.57271 > 192.168.90.2.179: Flags [S], seq 3717540734, win 16384, options [mss 9152,sackOK,eol], length 0
07:49:03.714669 (authentic,confidential): SPI 0xc92d0d56: IP 192.168.90.1.57271 > 192.168.90.2.179: Flags [S], seq 3717540734, win 16384, options [mss 9152,sackOK,eol], length 0
#12 Updated by Jim Pingle 11 months ago
This site isn't good for discussion and diagnosis of that nature, please post on the forum and we can talk about it there. Please include any other related configuration info such as the assigned interface settings.
For the route table output, use
netstat -rnW for wide output so the interface name is not cut off.