Am 16.08.2018 um 12:30 schrieb David Woodhouse: > On Thu, 2018-08-16 at 12:22 +0200, Jeroen Balduyck wrote: >> That's not what I meant. Sorry if I caused some confusion. I'm talking >> solely about the *private* tunnel endpoints. So not the *public* >> tunnel endpoints. Let's untangle the question a bit. So this is my >> interface again: >> >> utun2: flags=8151 mtu 1340 >> >> inet 10.23.167.57 --> 10.23.167.57 netmask 0xffffffff >> >> So 10.23.167.57 is my (= on my router) private tunnel (end)point. The >> "-->" points to the next hop gateway which is ...again the exact same >> private tunnel endpoint 10.23.167.57. I would have expected the >> private tunnel endpoint of the *ocserver* side here which cannot be >> 10.23.167.57 as that is the IP on my router. >> >> When I do a traceroute you see the next hop is actually 10.65.0.1: > In an Ethernet network, what does it mean to send packets "to" the > gateway? > > The destination IP address in the packets is still the real destination > of the packet, of course. We use the gateway for the ARP or ND lookup, > purely to find the correct Ethernet MAC address. > > This isn't relevant for a VPN tunnel; we don't have to put a "hardware > address" on the packets; we just shove them down the pipe. So the > "gateway" is largely irrelevant. In the BSD world this mostly ends up > showing the *local* address as the "gateway" in this context. > > It's basically cosmetic. Hi, I have to jump in into this discussion. I built the OPNsense plugin for OpenConnect which is based on FreeBSD. The routing behaviour doesn't work everytime as expected. Let's say I push 10.10.0.0/24 via a ASA. From the CLI I can reach 10.10.0.5 via ping or telnet to 3389 or whatever. But when I use a service like siproxd and bind it to tun interface, it loops to itself since it wants to reach it's own VPN IP. ATM I'm unsure if it's related to FreeBSD or the FreeBSD implementation of OC. Regards, Michael
