44net

44net@mailman.ampr.org

2 participants
3201 discussions

Re: [44net] Problem with drop non 44/8 trafic via tunnel
by Rob Janssen 21 Aug '16

21 Aug '16

> I have use tcpdump to check how working iptables > I have try block this traffic by > but not working for me Again: you can NOT test it this way! tcpdump will show you all packets even when you are dropping them in the filter. I know this is sometimes a nuisance. It is difficult to test if your filters are working. When your filter has the structure of: - some packets dropped - some other packets dropped - more packets dropped - all remaining packets accepted (note that this is normally not a preferred structure of your blocklist) you can work around it by inserting a rule like this just before the last ACCEPT rule (or at the end of the table when the default setting is ACCEPT, again not a preferred situation): iptables -A INPUT -i tunl0 -j NFLOG --nflog-group 44 This will send the packets to a "netfilter logging" interface where you can trace it with: tshark -i nflog:44 (I don't think tcpdump supports dumping nflog interfaces but this may depend on version) The result of this is that all packets that have already been dropped above that rule will not reach the NFLOG target and will not be traced when you trace nflog:44. However, it is normally preferred to work with a "default drop" setup. You accept all packets that you know you want to accept, and drop everything else at the end of the table. This makes it less likely that things pass by that you did not think about, like other protocols than TCP and UDP. It is still possible to have NFLOG logging of everything that is accepted, by first creating a helper table like this: iptables -N NFLOGACCEPT iptables -A NFLOGACCEPT -j NFLOG --nflog-group 44 iptables -A NFLOGACCEPT -j ACCEPT Then you setup your filter table like this: iptables -A INPUT -i tunl0 -..... -j NFLOGACCEPT iptables -A INPUT -i tunl0 -..... -j NFLOGACCEPT iptables -A INPUT -i tunl0 -j DROP Rob

1 0

Re: [44net] Problem with drop non 44/8 trafic via tunnel
by Rob Janssen 20 Aug '16

20 Aug '16

> I have try block non 44/8 traffic via tunnel IPIP with iptables but without > success > I have use ampr-ripd to create port 'tunl0' > I have add to firewall rule: > iptables -A INPUT -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP > iptables -A FORWARD -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP > but I have still a lot of traffic via tunl0 non 44/8 ip address and it is > look like this not working for me How did you validate that you still have the traffic? Does such traffic still reach an open port on your system or a system behind it? E.g. when you have telnet or ssh running, can you still telnet or ssh from internet? Note that using a trace tool like "tcpdump" or "tshark/wireshark" is NOT a valid way of testing of those filters work! When you do "tshark -i tunl0" with the above filters in place, you will still see the traffic. This is because tshark and tcpdump trace the real traffic on those interfaces BEFORE the filters have been applied. Rob

1 0

Problem with drop non 44/8 trafic via tunnel
by Waldek Waldek 20 Aug '16

20 Aug '16

Hi I have try block non 44/8 traffic via tunnel IPIP with iptables but without success I have use ampr-ripd to create port 'tunl0' I have add to firewall rule: iptables -A INPUT -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP iptables -A FORWARD -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP but I have still a lot of traffic via tunl0 non 44/8 ip address and it is look like this not working for me I have add one more rule like where eth0 is my internet port iptables -A OUTPUT -o eth0 -s 44.0.0.0/8 -j DROP and it is help me to not send to internet 44/8 ip traffic but I would like block incoming non 44/8 IP address via tunnel -- Waldek sp2ong

1 0

Re: [44net] iptables
by lleachii＠aol.com 17 Aug '16

17 Aug '16

It appears the the iptables rule is incorrect. In my previous configuration I had a border device NATing to a downstream device running as my AMPRNet Gateway. When I first set it up, I had THE EXACT SAME ISSUE YOU ARE EXPERIENCING. I could only receive packets after first initiating them. When asking for advice, I continued to receive information that the iptables rules were correct... THEY WERE NOT!!! Why??? As you are receiving this traffic the router interface, IT IS CONSIDERED INPUT since there are no routing rule to forward the packet (this is only done the subsequent DNAT rule added to the iptables firewall). This is an example from my DD-WRT device when I DNATed to a IPIP gateway downstream (so, this is a known working configuration): # iptables -t filter -I INPUT -p 4 -i eth0.1 -j ACCEPT # iptables -t nat -I PREROUTING -p 4 -i eth0.1 -j DNAT --to-destination 192.168.0.11 Further, on the INPUT rule, you could use the -d argument and the IP address if your WAN interface has a static address. Also, after I added this rule to my device, the issue Rob describes doesn't occur (except when I explicitly added a rule to block Pings). 73, - Lynwood KB3VWG

2 1

Re: [44net] iptables
by Rob Janssen 17 Aug '16

17 Aug '16

> It is behind my ISP cable modem, I had to get it setup in bridging mode > after the last time they upgraded it. My router is showing all the > tunnel traffic (via tcpdump) so I'm fairly certain the modem isn't the > issue. Ok. I heard before from other members of this group that they had a similar setup, yet I was never able to ping them unless they first pinged me. > Central to my confusion at the moment is the rule in the nat PREROUTING > isn't counting packets. Remember that iptables NAT processing in Linux is stateful. It only sees "new" traffic for a connection. Once a connection is in the NAT table, the traffic goes "around" those rules much like Established/Related traffic in the filter tables, but without an explicit visible rule for that purpose. So, when you ping outward over a tunnel, you will not see those rules matching yet the traffic is forwarded as reply to your outgoing pings. Only when you ping from somewhere else, those rules are going to be of influence. But of course they only see traffic when it actually arrives on your router. Rob

2 1

Re: [44net] iptables
by Rob Janssen 17 Aug '16

17 Aug '16

> The latest reboot had me digging deeper to try to find the real problem > and I have discovered that only the rule in FORWARD chain of the filter > table is firing, not the DNAT in the nat table. I suspect the firewall > is only working when some connection (outgoing ?) wakes up the > masquerade rules but haven't actually found the rule that is active. Are you sure the OpenWRT box is actually seeing the incoming packets? Is it directly on the internet, or is there another box before it, e.g. an ISP provided modem/router? Even though you might have forwarded the protocol or even set the OpenWRT box as the "DMZ device", it may still do stateful firewalling on non-TCP/UDP protocols. That is a known problem with NAT routers. Try to run a trace on the OpenWRT box to verify that you can receive IPIP traffic from sources that you have not recently contacted with outgoing traffic. Rob

2 1

Re: [44net] TAPR DCC 2016 - anyone going?
by Rob Janssen 16 Aug '16

16 Aug '16

> I think with much larger address space and the availability of /56 or > larger spaces for many connections means many of us already have excess, > the second approach is worth investigating. Come up with DNS management > and a system for automatically configuring AMPRNET6 routers to share > trust information to tie the network together securely. As I said > before, I could easily allocate part of my /56 to this project. I'm > using less than 1% of my address range (1/256th to be exact :) ). Address space is not an issue with IPv6. Everyone here gets a /48 with their home internet connection. I use only 3/65536 of mine :-) For a "global IPv6 space for amprnet" we would get a /32 and map it 1:1 with the existing net-44 addresses. That will give every net-44 IP user a /56 network on IPv6. However, I too don't think is the way to go. Just use the space you get on your own internet connection for your own purposes on AMPRnet (and nag the ISP when they don't provide IPv6, give you only a /128 or /64, or assign dynamic prefixes - bad concepts in IPv6 rollout!). Extend the current DNS server and robot with AAAA records, and find or design some method of sharing the prefix list. Could be done using a BGP server. (not the internet BGP but a server on AMPRnet that distributes prefixes) Then we can interconnect on internet without the hassle we have now, and still are able to route the same addresses over wireless networks. Rob

2 1

iptables
by Niall Parker 16 Aug '16

16 Aug '16

Hello, I seem to have something broken on my firewall for redirecting incoming ipip packets to my gateway box. It appears to work fine at times but fails periodically, typically after a reset/power failure. Usually it comes back after several reboots of firewall and router but this process is inconsistent. The latest reboot had me digging deeper to try to find the real problem and I have discovered that only the rule in FORWARD chain of the filter table is firing, not the DNAT in the nat table. I suspect the firewall is only working when some connection (outgoing ?) wakes up the masquerade rules but haven't actually found the rule that is active. The firewall is running on OpenWRT using iptables (old version 1.3.8) and the rules as I think they should work are ## for ampr.org tunnels iptables -t nat -I PREROUTING -p 4 -i eth0.1 -j DNAT \ --to-destination 192.168.99.66 iptables -t filter -I FORWARD -p 4 -i eth0.1 -j ACCEPT As I understand it, the first re-writes the destination for ipip packets to my gateway and the second allows them to be forwarded however the counter on first stays stuck at 0. A reference to what sounds like a similar problem: https://sourceforge.net/p/ipcop/mailman/message/17780204/ It would be really nice to get this sorted properly, any debugging hints appreciated. In particular, am I correct in expecting both rule counters to match ? thx ... ... Niall

1 0

Connecting to amprnet
by Jon A 16 Aug '16

16 Aug '16

Hi folks, I have a /29 subnet allocated and have been with interconnecting a few systems but want to expand that connectivity to other systems round the world. Last time I experimented with amprnet was 15 years ago and I had a ipip tunnel to a packet node that also had amprnet connectivity. That node is long gone so looking for something else to use. Reading info on the wiki, it sounds like I can now use rip and connect via the UCSD router. Have I under stood this correctly? Any idiot guides out there on how to do this or any suggestions on other ways I can connect to a gateway? Thanks Jon M1CQO

4 4

TAPR DCC 2016 - anyone going?
by Brian Kantor 15 Aug '16

15 Aug '16

I'm unable to attend the 2016 TAPR DCC next month in St Petersburg Florida. If anyone on this mailing list is going to be there, could you please let us know the substance of any discussions relevant to the AMPRNet. Thank you. - Brian

8 13

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net