Feature #8544
closed
Routed IPsec using FreeBSD if_ipsec(4) VTI
Added by Jim Pingle almost 6 years ago. Updated over 5 years ago.
100%
Description
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.
Updated by Jim Pingle almost 6 years ago
- Status changed from Assigned to Feedback
- % Done changed from 0 to 100
Applied in changeset bd4c337c061f989c4be1bbeaf207447cd8af4989.
Updated by Jim Pingle almost 6 years ago
Once a new snapshot is up with the later two commits it should be OK for testing.
Updated by Michael OBrien almost 6 years 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!
Updated by Jim Pingle almost 6 years 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.
Updated by Jim Pingle almost 6 years ago
- Status changed from Assigned to Feedback
Changes pushed, next snapshots should be better for testing.
Updated by Jim Pingle almost 6 years 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.
Updated by Jim Pingle almost 6 years 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.
Updated by Jim Pingle almost 6 years ago
- Status changed from Assigned to Feedback
Applied in changeset aea2a0c333407c0d8b74a51a9dec0829dc78db72.
Updated by Jim Pingle almost 6 years ago
Another fix in d4b43c48ed1636d3fcd6e47d73ba721bd63d883a
Updated by Aidan Mountford almost 6 years ago
Howdy,
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!
ifconfig:
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
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
reqid: 2000
groups: ipsec
Route table: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
Updated by Aidan Mountford almost 6 years ago
I should note that ipsec2000 is clipped to ipsec200 in the above
Its also worth noting that on the ifconfig the interface is not identified as "RUNNNING" in the flags.
Many thanks
A
Updated by Jim Pingle almost 6 years 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.
Updated by Jim Pingle over 5 years ago
- Status changed from Feedback to Resolved
The core of this is solid. Any other issues that come up can be handled as separate tickets.