6 Jun
2017
6 Jun
'17
11:22 p.m.
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?
--
Tom Cardinal/N2XU/MSgt USAF (Ret)/BSCS/CASP, Security+ ce
7 Jun
7 Jun
2:34 a.m.
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
4:10 a.m.
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
5:07 a.m.
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).
5:12 a.m.
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.
5:28 a.m.
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.
5:57 a.m.
Lynwood,
It seems that you have your own visions on how this all works. I will
refrain from any comment from now on.
6:21 a.m.
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
8:45 a.m.
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.
8 Jun
8 Jun
4:54 a.m.
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
9:38 a.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
10 a.m.
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
7 Jun
7 Jun
4:24 a.m.
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
4:46 a.m.
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.
2535
days inactive
2536
days old
14 comments
5 participants
participants (5)
-
ki4szj＠gmail.com -
lleachii＠aol.com -
Marius Petrescu -
marius＠yo2loj.ro
-
Tom Cardinal