dual stack openvpn and routing problem: MULTI: bad source address from client [xxxx::xxxx]

[therrmann]

I have the following setup running smoothly for a long time. The icinga server in the company network monitors various services on a home server through direct IPv6 connectivity (no VPN, no NAT).

Code: Select all

+-------------------------------------------------+
|  company network     +----------------------+   |
|                      |      icinga          |   |
|                      |  | ^                 |   |
|                      +--+-+-----------------+   |
|                         | |                     |
|            +------------+-+----------+          |
|            | router     | |          |          |
|            |            | |          |          |
+------------+--^-+-------+-+----------+----------+
                | |       | |
                | |       | |
           +----+-v-------+-+--------------+
           | internet     | |              |
           +----^-+-------+-+--------------+
                | |       | |
                | |       | |
+---------------+-v-------+-+---------------------+
|  home office            | |                     |
|                     +---+-+-----------------+   |
|                     |   v |                 |   |
|                     |        home server    |   |
|                     +-----------------------+   |
+-------------------------------------------------+

Now I needed to connect the home server to the company internet via OpenVPN, It works flawlessly, I can connect to the whole company network using IPv4 (NAT) and IPv6 (official IP addresses but routed though OpenVPN). Everything works, except the monitoring traffic from the icinga server is delivered to the home server directly and the replies travel through the OpenVPN (because the route matches more closely).

Code: Select all

+-------------------------------------------------+
|  company network     +----------------------+   |
|                      |      icinga          |   |
|                      |  |                   |   |
|                      +--+-------------------+   |
|                         |                       |
|            +------------+------------+          |
|            | router     | X      vpn |          |
|            |            | |   ^ |    |          |
+------------+--^-+-------+-+---+-+----+----------+
                | |       | |   | |
                | |       | |   | |
           +----+-v-------+-+---+-+--------+
           | internet     | |   | |        |
           +----^-+-------+-+---+-+--------+
                | |       | |   | |
                | |       | |   | |
+---------------+-v-------+-+---+-+---------------+
|  home office            | |   | |               |
|                     +---+-+---+-+-----------+   |
|                     |   v |   | v           |   |
|                     |        home server    |   |
|                     +-----------------------+   |
+-------------------------------------------------+

This by itself would not be a problem, but OpenVPN refuses to deliver the packets, they are discarded in the router that runs the OpenVPN (marked with the X in the graphic above):

Code: Select all

Feb  9 11:34:35 routersrv1 ovpn-server[1349]: JohnDoeProxmox/11.22.33.44:58491 MULTI: bad source address from client [2003:12:34:56:aaaa:bbff:febb:cccc], packet dropped

I don't think it's an iptables issue, the routerserver should know where to deliver the packets. Any ideas where to start fixing this?

I can post the whole config, although I don't think it is necessary, it is more of a routing problem than a classic openvpn issue. My home office has a dynamic IPv6 subnet, so adding manual routes would be difficult.

Regards and thanks for all types of help
Thomas

[TinCanTech]

Your server does not know the source IP address of the client packet because it is coming from the wrong client interface.

[therrmann]

Your server does not know the source IP address of the client packet because it is coming from the wrong client interface.

True. But is this a problem? Routing should be done based on destination addresses, and the server does know a route for that destination. Is this "bad source address" some kind of sanity filter that can be turned off?

[TinCanTech]

Routing should be done based on destination addresses

This is in the openvpn routing table not the kernel routing table.

is this a problem?

If you haven't noticed it until now then it probably isn't a problem.

[therrmann]

This is in the openvpn routing table not the kernel routing table.

OK. Is it possible to tweak this table manually?

If you haven't noticed it until now then it probably isn't a problem.

Well, I changed my setup with the result that _one_ use case isn't working anymore. So yes, this is a problem for me.

If I am doing something fundamentally wrong, please let me know. I just wonder what's the best way for native IPv6-Connectivity and VPN-Connectivity to coexist. I find it hard to believe that I am the only one with this issue.

[TinCanTech]

The problem comes from your application or system, using the wrong egress interface for VPN bound traffic.

If the application is broken by this for only this client then your application may be bugged.

You can enable Openvpn server to understand this clients other interface address by using a CCD file and an --iroute.

See the howto on Expanding the scope to include ..

[therrmann]

I am not sure which "application or system" you are referring to. Basically, the icinga server sends ICMPv6 pings to the home server, which is a standard linux machine. It responds to the pings by chosing a different route than the incoming requests. So the only application/system involved is basically a standard linux.

Since my home server's ipv6 prefix is dynamic, I don't know how to add it to CCD file. I know the iroute parameter and have used it to connect networks. I thought its main reason was for the server to know which packets to send into the tunnel, but it seems to be used for packets coming in over the tunnel as well.

Thanks for your patience, but I am still lost. The howto articles are usually referring to ipv4 only rfc1918 networks with NAT. That case is trivial.

[TinCanTech]

It does not make any difference which protocol is in use, your client is using the wrong egress interface for some application.

We need some details viewtopic.php?f=30&t=22603