This could be me or maybe not.
I got online a few weeks ago with Lynwood's help without it I'd still be offline. Since then I've been attempting to take my script apart and put it back together in an attempt to understand what makes it work and what breaks it
From a workstation on my segment I am able to ping, browse and pretty much do anything I'd expect to be able to do. The problem arises if I attempt to ping or traceroute on my gateway to anything in the AMPRnet. No matter what routes exist in my routing table (44) and what rules I create, any and all attempts to connect to an AMPR ip INSIST on going out through eth0 OR tries to use the external IP of my gateway box on the tunl0 interface.
I'm using an ubuntu 16.04 lts box with the latest ampr_ripd (2.3). Configuration is: eth0 - isp provided address (DHCP) (IPTables Masqueraded interface for LAN) eth1 - home LAN on RFC 1918 IP space 192.168.1.254/24 eth2 - 44.98.63.6/29 My AMPR segment tunl0 - Tunnel to the rest of the AMPRNET. (no IP Address assigned)
Asi Isaid earlier, from the gateway I can't initiate connections through the tunl0 interface even though everything works from an AMPR IP (listed in DNS) on my segment. I'm putting my start script up here. Firewall is in a separate script with nothing blocked at the moment (wide open), I normally run a pretty restrictive firewall and will re-lock it down when I get things sorted out.
---- startampr script ---- #!/bin/sh ### ENABLE IP FORWARDING ### sysctl -w net.ipv4.ip_forward=1 ### Allows traceroute to respond using 44net IP of tunl0 or br-amprlan echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr ### AMPRNet IPENCAP ### modprobe ipip ip tunnel add tunl0 mode ipip ### Bring the tunl0 interface up ### ip link set tunl0 mtu 1480 up ip tunnel change tunl0 ttl 64 pmtudisc ### ROUTING ### Set default route ip route add default dev tunl0 via 169.228.34.84 onlink proto 44 table 44 ### OPTIONAL LOCAL RULES ip rule add from 44.98.63.0/29 to 192.168.1.0/24 table main priority 22 ip rule add from 192.168.1.0/24 to 44.98.63.0/29 table main priority 23 ####REQUIRED RULES ### Handles routing between local AMPR segment and External AMPR network ip rule add to 44.98.63.0/29 table main priority 44 ip rule add dev tunl0 table 44 priority 45 ip rule add dev eth2 table 44 priority 46 ip rule add from 44.98.63.0/29 table 44 priority 47 ### RUN AMPR-RIPD /usr/sbin/ampr-ripd -i tunl0 -t 44 -a 44.98.63.0/29 -s -x '/etc/ampr/load_ipipfilter.sh' -p <password> #### End startampr script ####
If I try to add a route to 44.0.0.0/8 with this command: ip rule add to 44.0.0.0/8 table 44 priority 48
and then I do "ip route get 44.0.0.1" I get the following output: root@blackjack:~# ip route get 44.0.0.1 44.0.0.1 via 169.228.34.84 dev tunl0 src 68.109.14.113 cache window 840
When the priority 48 rule in place, my workstation on my 44net segment loses connectivity through the tunnel... Perhaps my ip rule commands are incomplete. I know I'm close, but what am I missing? Are there any policy routing experts that can help explain what I'm missing and why what I have doesn't work if I try to ping/traceroute/mtr on the gateway?
By not setting an IP on your tunnel, you are sending all traffic originating on your gateway with an outgoing IP other than your 44net address (as seen in the output of the ip route get command).
You are creating exactly the situation Brian is fighting for some time now.
Your tunnel should have either 44.98.63.6/32 or, even better, 44.98.63.6/8, which is the 'real' netmask of that tunnel.
For clarification: 44.98.63.6/8 means that behind that interface with IP 44.98.63.6 sits the whole 44.0.0.0 - 44.255.255.255 address space, which is the real situation.
This will create automatically a route 44.0.0.0/8 via tunl0 in the main table. Using a /32 netmask will avoid this.
On 07.06.2017 06:22, Tom Cardinal wrote:
This could be me or maybe not.
tunl0 - Tunnel to the rest of the AMPRNET. (no IP Address assigned)
...
If I try to add a route to 44.0.0.0/8 with this command: ip rule add to 44.0.0.0/8 table 44 priority 48
and then I do "ip route get 44.0.0.1" I get the following output: root@blackjack:~# ip route get 44.0.0.1 44.0.0.1 via 169.228.34.84 dev tunl0 src 68.109.14.113 cache window 840
Tom,
As far as I can see, the only problem is with the syntax of your command, you have to add the from IP to get the appropriate route:
root at blackjack:~# ip route get 44.0.0.1 from <IP_of_eth2>
- Re-run the command to check the route, then past the results. - ip route priority 23 is unnecessary, this route already exists on table main, and your systems uses it - Make sure you're assigning the /29 to eth2 - Have you DISABLED the PRE-CONFIGURED desktop firewall (if you're running a version other than server??? - Have you removed the basic IPTABLES rules (i.e. DROP FORWARD) from the desktop firewall???
As we've determined, an IP on tunl0 in Linux doesn't change what interface is used by the Kernel, specifying the interfaces does.
I'll look into amprd...although I'm not sure how it enables IPv4 forwarding, tunnels, etc. on Ubuntu/LEDE (must test).
- Lynwood KB3VWG
It doesn't. It is an user space encapsulation daemon. It does all RIP handling and routing inside the daemon, connects to the outside world via IPIP and creates a virtual ethernet interface providing 44.0.0.0/8 access.
I'll look into amprd...although I'm not sure how it enables IPv4 forwarding, tunnels, etc. on Ubuntu/LEDE (must test).
As we've determined, an IP on tunl0 in Linux doesn't change what interface is used by the Kernel, specifying the interfaces does.
But it determines the source address of the machine local outgoing traffic. It seems no one is bothered to correct this, even if it is classified as an error and dropped by the gateway.
Marius,
My friend, I updated Startampr Wiki on Monday. As of version 2.3, my script reads that an IP on tunl0 is *required*.
At least on Linux, the outgoing IP on WAN takes priority, since it's the only one with a "Gateway IP" entry in /etc/interfaces. Routers can't "guess" which outbound to use. Once you coded -i into ampr-ripd, my discoveries disappeared, just like my pings using tunl0. Adding an IP has never had an effect, unless I wanted to test ping using tunl0. Never seen a "failure," as the IP is optional to the OS. Your coding on -i makes it required to use -L.
http://wiki.ampr.org/wiki/Startampr#Script
I also contacted Tom off-thread about it, as it seems he may be trying to run his machine as a desktop. If that's the case, his issue is that he has to configure the user applications to use tunl0, or simply virtualize the AMPR desktop and connect it's virtual-NIC to eth2.
73,
- Lynwood KB3VWG
But it determines the source address of the machine local outgoing traffic. It seems no one is bothered to correct this, even if it is classified as an error and dropped by the gateway.
Lynwood,
It seems that you have your own visions on how this all works. I will refrain from any comment from now on.
Marius,
Perhaps we're lost in translation. I have no application installed on my router that needs tunl0, until you released ampr-ripd v2.3. This is important because this -L argument could cause issues in the future.
My device *only* routes traffic, so no application uses tunl0 except the -L argument of ampr-ripd.
*I've never needed to assign a OSI Layer 3 address to a PHY not used on Layer 3.* Only my 44bridge and 44 devices use 44IPs, and they all use tunl0. Only they sit on tables that use tunl0, and the rules point to those IP and interfaces to use...table 44! Those routes use tunl0 ONLINK. If you ping my device br-amprnet responded, everything worked as you described, except no IP is necessary, until you placed Layer 3 into ampr-ripd.
- KB3VWG
This is not the case. I'm running ubuntu server. The only client type software I use on it is traceroute. It never occurred to me to specify the interface and tell it to use eth2. Will try it along with Marius' suggestion to put 44.98.63.6/8 on tunl0. I had 44.98.63.6/29 on it as a test in the past and expected an IP conflict but the kernel never complained. The 63.6/8 is new ground an I'm going to try it along with specifying the interface when I do ping, mtr and traceroute.
--tom N2XU / Tom Cardinal MSgt USAF(Ret) / BSCS / CASP, Security+
On 06/07/2017 04:28 AM, lleachii--- via 44Net wrote:
I also contacted Tom off-thread about it, as it seems he may be trying to run his machine as a desktop. If that's the case, his issue is that he has to configure the user applications to use tunl0, or simply virtualize the AMPR desktop and connect it's virtual-NIC to eth2.
Tom,
Will try it along with Marius' suggestion to put 44.98.63.6/8 on tunl0.
I'm not 100% sure this works on Linux, you should probably use a /32 from your allocation:
- Packets comes to your border for your subnet - Your tunl0 is in the network 44.0.0.0/8 - It has no need to forward the packet
The mere fact that the single IP is not assigned may work (i.e. kmod-ipip removes the header and places it in the netfilter chain); but if you were to change ip rules, this might cause an anomaly. Using /32 is better, I recall that being our friend's suggestion to me over the years.
- KB3VWG
Yep... /32 works perfectly. Also had to add a rule (priority 48) to use table 44 on my router whenever I go to 44 land from the router... Rules in place at the moment are:
These are the ones I learned from you. I've done extensive experimentation and modifications to them to break them and see what makes them tick... ip rule add to 44.98.63.0/29 table main priority 44 ip rule add dev tunl0 table 44 priority 45 ip rule add dev eth2 table 44 priority 46 ip rule add from 44.98.63.0/29 table 44 priority 47
These next two I found are necessary: The priority 48 rule forces my lan machines to NOT use my AMPR tunnel to go to other 44/8 addresses. It removes the need for me to NAT, but more importantly it prevents others (unlicensed) who have access to my wireless lan (nieces/nephews, sister-in-law) from going anywhere on AMPRnet unless they access publicly available sites through the AMPR gateway. ip rule add from 172.27.141.0/24 to 44.0.0.0/8 table main priority 48
Priority rule #49 is the magic sauce that allows me to use the router (my AMPR gateway) to perform network tests (mtr, traceroute, ping etc) from the router to other 44/8 space. Without it these network tests go out the external interface and in through the AMPR-GW. I've tested with the rule in place and disabled and it works exactly as I expect. ip rule add to 44.0.0.0/8 table 44 priority 49
So... I've arrived at what I would call the final solution for my startampr script. It's been a bumpy road and I would have never gotten here or learned what I've learned thus far without your assistance. I'm currently working on the firewall script to protect the router. I'm including stuff I learned from your ipipfilter.sh bogon filter and I'm also including my adaptive firewall from the past that handles brute force attackers (aka script kiddies) in real-time. I've seen lots of attempts to get in to my SSH port mainly from CN and RU based (ipdeny.com) IP space...
I'll be publishing my long bumpy road once I get the firewall stable and my web server registered in DNS... at last check Jerry hasn't responded to my requests to modify my DNS entries.
---tom Tom Cardinal/N2XU/MSgt USAF (Ret)/BSCS/CASP, Security+ ce
On 6/8/2017 03:54, lleachii--- via 44Net wrote:
Tom,
Will try it along with Marius' suggestion to put 44.98.63.6/8 on tunl0.
I'm not 100% sure this works on Linux, you should probably use a /32 from your allocation:
- Packets comes to your border for your subnet
- Your tunl0 is in the network 44.0.0.0/8
- It has no need to forward the packet
The mere fact that the single IP is not assigned may work (i.e. kmod-ipip removes the header and places it in the netfilter chain); but if you were to change ip rules, this might cause an anomaly. Using /32 is better, I recall that being our friend's suggestion to me over the years.
- KB3VWG
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Tom,
Kool! That priority 48 may need the AMPRNet to masquerade from non-44 LAN to AMPRWAN.
The priority 47 is good too. In my circumstances, I need to select the interface each time; because I have downstream routers that I need to trace/ping.
N1URO just remarked to me about AMPRNAT - that most OPs seem to expect traffic destined for 44 to go there via tunl0. We can work on making those notes on the respective Wikis.
Congrats!
73,
- KB3VWG
Tom,
The command in the bottom of your email won't quite work as I think you intend. In fact, this rule:
- only manages to force your WAN AND 192.168.x.x to tunl0, you would have to masquerade traffic from 192.168.x.x to 44.0.0.0/8 if that's your intent - as you know, it's impossible for your WAN to 'use' tunl0 - this rule probably causes traffic to Direct44 subnets to fail too
- KB3VWG
ip rule add to 44.0.0.0/8 table 44 priority 48
Tom,
Are you trying to use your border router as a desktop, and configure it to use AMPRNet??
If so, I don't suggest using a desktop OS as both a desktop and router.
- KB3VWG
Asi Isaid earlier, from the gateway I can't initiate connections through the tunl0 interface even though everything works from an AMPR IP (listed in DNS) on my segment.
-
ki4szj＠gmail.com -
lleachii＠aol.com -
Marius Petrescu -
marius＠yo2loj.ro
-
Tom Cardinal