[nos-bbs] Not Sure if my IPtables forwarding RIP is working

Boudewijn (Bob) Tenty bob at tenty.ca
Sun Dec 18 17:43:47 EST 2022


Oops, I mean to jnos

On 2022-12-18 17:39, Boudewijn (Bob) Tenty wrote:
> If you want to have the rip broadcast by ucsd populate the route table for ipip in Linux
> you'll need to have a daemon running like, ampr-ripd what is listening for these broadcasts.
> Without a daemon (and so a tunl0 interface) you will see no ipip routes in the table.  If you
> want this to handled by jnos instead, you'll have to forward it jnos. All most all gateway
> operators have a deamon running in Linux.
>
> Bob VE3TOK
>
> On 2022-12-18 11:59, Chris Maness wrote:
>> I cross posted this on Reddit (I am disclaiming that fact as if it is
>> a sin, but don't know why it is a bad thing).  Read virtual host on
>> virtual lan tun/tap tun0 as JNOS and 4.3.2.1 as my GW address that is
>> on eth0 of this machine.
>>
>> I thought I had this right, but I am not seeing packets on the TUN/TAP
>> device to the virtual lan. The host that needs RIP2 data is on
>> 192.168.2.1 using the tun0 TUN/TAP on a Linux host. I am using
>> wireshark to see weather RIP is making it to TUN/TAP, but not sure I
>> understand that device correctly. I was thinking that I can see RIP
>> frames come in on eth0 and then subsequently see them on tun0 as it is
>> listed in wireshark. However, as I was composing this post, I realized
>> that the RIP packet may not need to be retransmitted on tun0 because
>> it acts like a wiretap on eth0 so would not need to have any frames
>> retransmitted on it, but I am not certain in this behavior. However,
>> the bottom line is RIP does not seem to be populating tables on the
>> 192.168.2.1 host. Public IP's in my example here has been obfuscated
>> by 4.3.2.1 -- take that as an IP exposed to the wild. Here are my
>> IPTABLES commands:
>> # iptables -t nat -A PREROUTING --dst 4.3.2.1 -p udp --dport 520 -j
>> DNAT --to-destination 192.168.2.1
>> # iptables -t nat -n -L
>> Chain PREROUTING (policy ACCEPT)
>> target prot opt source destination
>> DNAT udp -- 0.0.0.0/0 4.3.2.1 udp dpt:520 to:192.168.2.1
>> Chain INPUT (policy ACCEPT)
>> target prot opt source destination
>> Chain OUTPUT (policy ACCEPT)
>> target prot opt source destination
>> Chain POSTROUTING (policy ACCEPT)
>> target prot opt source destination
>> ###
>> I hope that is clear as to what I am trying to accomplish, and weather
>> or not this should work.
>> Thanks in advance,
>> Chris KQ6UP
>>
-- 
There is nothing permanent except change
  
-Heraclitus




More information about the nos-bbs mailing list