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

[Chris Maness]

Totally got that.  I have that daemon compiled.  I just wanted to see
if I could just pipe the RIP into JNOS with IPtables.  I may do it
that way, but feel compelled to try to figure out what went wrong with
my first idea as I would like to have a better understanding of
IPtables.

Chris KQ6UP

On Sun, Dec 18, 2022 at 2:44 PM Boudewijn (Bob) Tenty <bob at tenty.ca> wrote:
>
> 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
>
>
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/nos-bbs_lists.tapr.org



-- 
Thanks,
Chris Maness