10 Jan
2024
10 Jan
'24
7:15 p.m.
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>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
11 Jan
11 Jan
12:14 a.m.
Yes there is.
The RIP packets are sent to a multicast address. More precisely from
44.0.0.1 to 224.0.0.9.
I hope this helps,
Marius, YO2LOJ
On 10/01/2024 21:15, Lee D Bengston via 44net wrote:
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
12:23 a.m.
And there is another thing:
While all other IPENCAP packets originate form let's say 3rd party IPs,
the packets holding the encapped routes are the only ones originated
from the ampr-gw itself (169.228.34.84), which is also the tunnel endpoint.
There could be some issues related to this fact.
On 11/01/2024 02:14, Marius Petrescu via 44net wrote:
Yes there is.
The RIP packets are sent to a multicast address. More precisely from
44.0.0.1 to 224.0.0.9.
I hope this helps,
Marius, YO2LOJ
On 10/01/2024 21:15, Lee D Bengston via 44net wrote:
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
_______________________________________________
44net mailing list --44net(a)mailman.ampr.org
To unsubscribe send an email to44net-leave(a)mailman.ampr.org
22 Jan
22 Jan
3:14 p.m.
New subject: RIP Packet Issue (Solved)
Update - spun up a new VPS and re-did the server and client setup using the
standard openvpn app from the Debian repo. Then added NFTables rules to
send packets from the Internet to where they needed to go.
The OpenVPN Access Server is a nice application, but it created a maze of
new chains and rules that were hard to follow, and somehow it was grabbing
the RIP packets separately. Also if I used its DMZ feature to forward
specific traffic from the Internet to clients, it would add a snat rule and
change the internet source address to the private VPN gateway address. I
had to find the offending snat rule in NFTables and delete it.
Now that the Access Server is out of the equation, everything works as
desired.
Thanks & 73,
Lee K5DAT
On Wed, Jan 10, 2024 at 1:15 PM Lee D Bengston <kilo5dat(a)gmail.com> wrote:
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>
108
days inactive
120
days old
3 comments
2 participants
participants (2)
-
Lee D Bengston -
Marius Petrescu