0

I have a multicast routing setup with forwarding on the receiving side, as follows (all Linux):

+----------------+            +----------------+                   +-------------+
| openvpn-server |tun0    tun0| openvpn-client |  forward port 53  | application |
|    10.8.0.1    |============|    10.8.0.2    |-------------------| 172.16.3.3  |
+----------------+            +----------------+                   +-------------+
                               joined 239.1.2.3
                               multicast group

In this set up, the openvpn-server side sends UDP packets to the multicast group 239.1.2.3 on port 53. Specifically, the packets are DNS NOTIFY messages, but I don't think this is of relevance here. (There are several instances of openvpn-client which is why multicast is used.)

openvpn-client then forwards the traffic to application. This host acknowledges the receipt of the packet by replying with another UDP packet.

The response packet is sent back to openvpn-client where Linux translates the source IP back to the destination IP address of the initial packet as it was coming in from openvpn-server (assuming that the original destination will now be the sender of the response), i.e. 239.1.2.3. This is the problem: Due to this source IP, the packet does not get transmitted to the original sender of the first packet, and the sender thinks the packet was not transmitted. This results in several unnecessary retries and a lot of logging.

The question is if it is possible to instruct openvpn-client to rewrite the source address of the response to 10.8.0.2 instead. More specifically, I would like it to be the address associated with interface tun0, such that things remain in order in case a VPN reconnect leads to an IP address change.

I suspect this is possible because iptables MASQUERADE does a similar thing (but for connections originating in application). Further, I believe that if I get this configured, the response packet would be delivered. Is this possible?

I observed that when I ping from 10.8.0.1 to 239.1.2.3, the echo packet originates from 10.8.0.2 (and not from 239.1.2.3). (Note that the ping case does not involve port forwarding.) How can I achieve the same behavior for my UDP case?

Peter Thomassen
  • 169
  • 1
  • 7
  • The application should open a unicast UDP socket to reply. Multicast addresses are not allowed to be source addresses on packets, so I'm not sure why the application would do that. It should not use the multicast socket it receives the original packet on to reply. Or maybe I am misunderstanding, and you are using NAT, which is unnecessary, and should only be used when necessary. NAT does not work correctly with multicast. – Ron Maupin Jan 24 '20 at 20:56
  • Yes, it is a NAT setup: If have configured port forwarding with NAT on openvpn-client so that multicast traffic on port 53 is forwarded to the application server. The application does use a unicast UDP socket, and things start going wrong when the reply's source address is rewritten during routing on openvpn-client. -- What's wrong with using NAT? My thinking was that with NAT, I can spare the application server from knowing anything about multicast. Isn't that a good reason? – Peter Thomassen Jan 27 '20 at 12:26
  • Multicast is used when you send to a group of interested hosts. Multicast addresses cannot be source addresses, only destination addresses. You cannot (or really should not) do a destination translation on multicast because your replies get a multicast source address, and that is wrong. – Ron Maupin Jan 27 '20 at 12:52
  • I understand that. My question is whether it is possible to only use DNAT (i.e. modifying the destination IP address for the purpose of port forwarding), and then somehow tweak the NAT that is applied to the response so that it will not use the multicast address, but instead the outgoing interface address as the source address. Do you know whether this is possible? – Peter Thomassen Jan 27 '20 at 13:31
  • NAT creates a table, and it will match the source and destination IP and UDP addresses and translate the packet on the return. You could use a different IP address or source port from the server back to the client to bypass the NAT table. In any case, you are simply not supposed to use NAT for multicast, it is for unicast packets. _Some_ enterprise grade routers have a translation for multicast, but it is to a different multicast group in only one direction. You are breaking the rules by translating multicast to unicast. – Ron Maupin Jan 27 '20 at 14:19
  • Thank you! That makes a lot of sense. – Peter Thomassen Jan 27 '20 at 14:34

0 Answers0