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] +-------------------------------------------------+ | company network +----------------------+ | | | icinga | | | | | ^ | | | +--+-+-----------------+ | | | | | | +------------+-+----------+ | | | router | | | | | | | | | | +------------+--^-+-------+-+----------+----------+ | | | | | | | | +----+-v-------+-+--------------+ | internet | | | +----^-+-------+-+--------------+ | | | | | | | | +---------------+-v-------+-+---------------------+ | home office | | | | +---+-+-----------------+ | | | v | | | | | home server | | | +-----------------------+ | +-------------------------------------------------+[/code] 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] +-------------------------------------------------+ | company network +----------------------+ | | | icinga | | | | | | | | +--+-------------------+ | | | | | +------------+------------+ | | | router | X vpn | | | | | | ^ | | | +------------+--^-+-------+-+---+-+----+----------+ | | | | | | | | | | | | +----+-v-------+-+---+-+--------+ | internet | | | | | +----^-+-------+-+---+-+--------+ | | | | | | | | | | | | +---------------+-v-------+-+---+-+---------------+ | home office | | | | | | +---+-+---+-+-----------+ | | | v | | v | | | | home server | | | +-----------------------+ | +-------------------------------------------------+ [/code] 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]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 [/code] 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

[quote=TinCanTech post_id=104825 time=1644410422 user_id=37053] Your server does not know the source IP address of the client packet because it is coming from the wrong client interface. [/quote] 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?

[quote=therrmann post_id=104845 time=1644486548 user_id=56167] Routing should be done based on destination addresses [/quote]This is in the openvpn routing table not the kernel routing table. [quote=therrmann post_id=104845 time=1644486548 user_id=56167] is this a problem? [/quote]If you haven't noticed it until now then it probably isn't a problem.

[quote=TinCanTech post_id=104848 time=1644504088 user_id=37053] This is in the openvpn routing table not the kernel routing table. [/quote] OK. Is it possible to tweak this table manually? [quote=TinCanTech post_id=104848 time=1644504088 user_id=37053] If you haven't noticed it until now then it probably isn't a problem. [/quote] 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.

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).

+-------------------------------------------------+
|  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).

+-------------------------------------------------+
|  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):

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

TinCanTech wrote 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

therrmann wrote Routing should be done based on destination addresses

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

therrmann wrote is this a problem?

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

therrmann

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

OK. Is it possible to tweak this table manually?

TinCanTech wrote 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 https://forums.openvpn.net/viewtopic.php?f=30&t=22603