The reason openconnect client doesn't put the real value is because it doesn't know it. The Cisco protocol was not sending that value and we had no reason to "fix" it in the openconnect protocol. On August 16, 2018 10:30:32 AM UTC, David Woodhouse <dwmw2 at infradead.org> wrote: >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. -- Sent from my mobile. Please excuse my brevity.
