Hairpin OpenVPN traffic across IPSEC VPNs to other sites
-
I have an XG-7100 with IPSEC VPN to two other sites, as well as Azure; call them Main, North, South and Azure.
I've observed:
- bi-directional traffic between North LAN and Main LAN
- bi-directional traffic between South LAN and Main LAN
- bi-directional traffic between Azure and Main LAN.
- bi-directional traffic from OpenVPN client to Main LAN
- I have included the OpenVPN subnet in phase 2 negotiations on both ends of specified IPSEC tunnels.
What I do not observe is traffic flowing from Main LAN to any other sites after arriving at OpenVPN ingress. I can resolve DNS lookups on OpenVPN clients for sites other than Main, but a route does not exist. When I trace route to sites beyond Main, the traffic goes out the un-encrypted gateway local to the OpenVPN client; it doesn't traverse the tunnel.
Do I have a reasonable expectation that I can route OpenVPN traffic accross IPSEC tunnels after the traffic arrives on the Main LAN?
-
If you have OpenVPN tunnel subnet defined in phase 2 policies on the IPSec tunnels (and they are up) it should carry any traffic that arrives for the remote sites.
It sounds like the OpenVPN clients do not have a route to those remote subnets. If they are not sending all traffic over OpenVPN then the IPSec remote subnets need to be added as local subnets in the OpenVPN server so routes get pushed to clients when they connect.
Steve
-
@stephenw10 To clarify, I am using the OpenVPN feature built into the XG-7100 versus a stand alone OpenVPN server. I don't see where I would put the routes, unless it would be in the general section for static routes.
FWIW, at South site I have a stand alone OpenVPN server that does allow hairpin traffic. At North site I use the built in OpenVPN in XG-7100 and it does not hairpin.
I suspect that the stand alone has more features.
-
You are using OpenVPN as remote access from individual clients yes?
Of you do not have
Redirect IPv4 Gateway
set in the server config the clients will only send traffic over the tunnel for subnets defined in theIPv4 Local network(s)
field. So you need to have the remote IPSec LAN subnets set there.Steve
-
@stephenw10 The reason I didn't choose that off the bat is, I don't want to route internet traffic through my LAN unnecessary. If I was doing content filtering, this would be necessary.
I did notice that I hadn't specified the additional site LANs in IPv4 Local network(s). After designating the RFC 1918 nets in this field, it worked good.
Thanks for the help.
-
You only need the actual subnets in use at your sites there rather than the full rfc1918 set. It will work though as long as clients don't need to route to anything in there locally.
Steve
-
@stephenw10 That's what I did, I just didn't want to specify how I've done the private subnetting. But that's a good point for anyone who stumbles
on this looking for a leg up.