Hello to those the list, I have a VPN server running on a VPS (OpenVPN Access Server). I also have the packet software XRouter (a.k.a. XRLin) running on the VPS. Normally it can get the routes from the amprnet RIP broadcasts. The VPN server uses a tunnel to send packets to my client. In the server to client direction it takes packets from the internet addressed to the static WAN address and changes the destination address to the client's VPN address - pretty standard stuff. The dnat results in the traffic being routed to the VPN tunnel. The OpenVPN Access Server writes rules to NFTables in order to handle the forwarding, dnat, etc. XRouter is set up with its own tunnel - somewhat similar to JNOS. I have added rules in NFTables to forward all transport protocol 4/encap packets to the XRouter tunnel. Included is a rule to dnat to Xrouter's address which is on the Xrouter side of the P2P tunnel. This setup is working for all encap packets EXCEPT the RIP packets. Checking things with TCPdump, the RIP packets are being dnat'd to the VPN tunnel address instead of the XRouter tunnel. I can't find any rules added by the OpenVPN server that are matching any encap traffic, so I'm baffled as to why they are not matched by my rules and also how they are matched by the VPN rules. That said, the VPN Access server creates a very confusing set of NTFable rules jumping all over the place though different chains, so it's possible that they lost me. However I asked a question on their forum a while back about support for protocol 4, and their answer was they don't support it. Is there anything about the RIP "IPIP" packets that is different from other "IPIP" traffic so that they would be handled differently by NFTables? Thanks, Lee K5DAT <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> _______________________________________________ 44net mailing list --44net(a)mailman.ampr.org To unsubscribe send an email to44net-leave(a)mailman.ampr.org

Hello to those the list, I have a VPN server running on a VPS (OpenVPN Access Server). I also have the packet software XRouter (a.k.a. XRLin) running on the VPS. Normally it can get the routes from the amprnet RIP broadcasts. The VPN server uses a tunnel to send packets to my client. In the server to client direction it takes packets from the internet addressed to the static WAN address and changes the destination address to the client's VPN address - pretty standard stuff. The dnat results in the traffic being routed to the VPN tunnel. The OpenVPN Access Server writes rules to NFTables in order to handle the forwarding, dnat, etc. XRouter is set up with its own tunnel - somewhat similar to JNOS. I have added rules in NFTables to forward all transport protocol 4/encap packets to the XRouter tunnel. Included is a rule to dnat to Xrouter's address which is on the Xrouter side of the P2P tunnel. This setup is working for all encap packets EXCEPT the RIP packets. Checking things with TCPdump, the RIP packets are being dnat'd to the VPN tunnel address instead of the XRouter tunnel. I can't find any rules added by the OpenVPN server that are matching any encap traffic, so I'm baffled as to why they are not matched by my rules and also how they are matched by the VPN rules. That said, the VPN Access server creates a very confusing set of NTFable rules jumping all over the place though different chains, so it's possible that they lost me. However I asked a question on their forum a while back about support for protocol 4, and their answer was they don't support it. Is there anything about the RIP "IPIP" packets that is different from other "IPIP" traffic so that they would be handled differently by NFTables? Thanks, Lee K5DAT <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_36578732419568539_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>