That occurred to me after I sent my last message. Part of my startup script included this default route:
ip rule add to 44.0.0.0/8 table 44 priority 44
So I commented that out, and then could reach hamwan.org, but wasn't able to reach hambook.de.ampr.org and other hosts. I also upgraded to ampr-ripd 1.13
If someone can reach both from their IPIP gateway I'd be most grateful if you'd share your startup script with me.
Here is my script: http://www.qsl.net/kb9mwr/wapr/tcpip/startampr
---- Quote ---- NO GATEWAY SHOULD EVER HAVE A DEFAULT 44/8 ROUTE TO UCSD BECAUSE IT DOESN'T WORK AND IS POINTLESS.
Marius, YO2LOJ
On Wed, Jun 17, 2015 at 2:09 PM, Steve L kb9mwr@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ That occurred to me after I sent my last message. Part of my startup script included this default route:
ip rule add to 44.0.0.0/8 table 44 priority 44
So I commented that out, and then could reach hamwan.org, but wasn't able to reach hambook.de.ampr.org and other hosts. I also upgraded to ampr-ripd 1.13
hambook.de.ampr.org has address 44.225.56.138.
That should be covered by this line in the encap, which should take priority over your less specific 44/8 route.
route addprivate 44.224/15 encap 141.75.245.225
Do you have this route?
Tom KD7LXL
Let me try to explain a little what's happening here...
Your system has usually 3 preexisting routing tables, 'local' (255),'main' (254) and 'default' (253). Usually, regular routes go to the table 'main', the table 'local' holds local interface IPs and broadcast routes, and the table 'default' is empty, and holds last resort routes. The specific 44 routes could go to table main, but for easier management, most OMs choos e separate routing table for those, in your case it is numer 44.
For the system to use table 44 for its decision on routing ampr traffic, a rule has to be set to specify to use another table than 'main'. This is done by 'ip rule add to 44.0.0.0/8 table 44', meaning 'all packets with destination 44/8 will use table 44' So, it will hold all '44.x.x.x/n via GW_Address dev tunl0' routes. To have a specific default route for 44 packets, something like '44/8 via something' has to be added. A specific default destination via your public interface should be added to table 44 if the IP falls trough without finding any matching subnet.
The stuff described up to this point, ensures IPIP tunnel and regular internet routing.
To be able to accept incoming connections from the internet, another step has to be taken, usually using another table (e.g. 'default' which is empty). To understand this, remember that internet to 44/8 will come through the default UCSD tunnel (where you get your RIP broadcasts, too), from a public IP to your 44 address. Responses to these requests have to go back to the same tunnel.
For this, we need a default route to ucsd in that separate table: 'ip route add default via 169.228.66.251 dev tunl0 onlink table default' And create our rule: 'ip rule add from (your ip/range) table default'
combined with the next rule: 'ip rule add from (your ip/range) to 44.0.0.0/8 table 44'
Take care that the rules are applied by priority, the newest added rule having precedence. So the order is important. Rules can be shown with 'ip rule list', the number shown being the priority, the lower the number, the higher the priority.
This gives the following behavior: - packets to from your 44 sources to 44/8 destinations will go via table 44 (directly to peers via IPIP) - on non match they (should) go to the default public IP interface - packets to from your 44 sources to non-44/8 destinations will go via table 'default' (and to ucsd via IPIP to their internet peers)
All other routing should be done in table 'main', e.g. for LAN and non 44net traffic.
CAVEAT: Contrary to routes, rules get not erased when bringing down an interface, so they must be explicitly deleted or set only once on system startup. Take care if restarting the interfaces by script.
I hope this explains some of the cryptic stuff.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Steve L Sent: Thursday, June 18, 2015 00:09 To: 44net@hamradio.ucsd.edu Subject: [44net] (no subject)
(Please trim inclusions from previous messages) _______________________________________________ That occurred to me after I sent my last message. Part of my startup script included this default route:
ip rule add to 44.0.0.0/8 table 44 priority 44
So I commented that out, and then could reach hamwan.org, but wasn't able to reach hambook.de.ampr.org and other hosts. I also upgraded to ampr-ripd 1.13
If someone can reach both from their IPIP gateway I'd be most grateful if you'd share your startup script with me.
Here is my script: http://www.qsl.net/kb9mwr/wapr/tcpip/startampr
---- Quote ---- NO GATEWAY SHOULD EVER HAVE A DEFAULT 44/8 ROUTE TO UCSD BECAUSE IT DOESN'T WORK AND IS POINTLESS.
Marius, YO2LOJ _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Steve, That's a rule directing your system to use routing table 44 for ampr purposes, not a route. It must be there, and it won't work without it.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Steve L Sent: Thursday, June 18, 2015 00:09 To: 44net@hamradio.ucsd.edu Subject: [44net] (no subject)
(Please trim inclusions from previous messages) _______________________________________________ That occurred to me after I sent my last message. Part of my startup script included this default route:
ip rule add to 44.0.0.0/8 table 44 priority 44
So I commented that out, and then could reach hamwan.org, but wasn't able to reach hambook.de.ampr.org and other hosts. I also upgraded to ampr-ripd 1.13
If someone can reach both from their IPIP gateway I'd be most grateful if you'd share your startup script with me.
Here is my script: http://www.qsl.net/kb9mwr/wapr/tcpip/startampr
The issue in your setup is 'ip route add default dev tunl0 via 169.228.66.251 onlink table 44' which should go away if ypu want to reach BGP announced networks.
Marius
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Marius Petrescu Sent: Thursday, June 18, 2015 01:42 To: 'AMPRNet working group' Subject: Re: [44net] (no subject)
(Please trim inclusions from previous messages) _______________________________________________ Steve, That's a rule directing your system to use routing table 44 for ampr purposes, not a route. It must be there, and it won't work without it.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Steve L Sent: Thursday, June 18, 2015 00:09 To: 44net@hamradio.ucsd.edu Subject: [44net] (no subject)
(Please trim inclusions from previous messages) _______________________________________________ That occurred to me after I sent my last message. Part of my startup script included this default route:
ip rule add to 44.0.0.0/8 table 44 priority 44
So I commented that out, and then could reach hamwan.org, but wasn't able to reach hambook.de.ampr.org and other hosts. I also upgraded to ampr-ripd 1.13
If someone can reach both from their IPIP gateway I'd be most grateful if you'd share your startup script with me.
Here is my script: http://www.qsl.net/kb9mwr/wapr/tcpip/startampr
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Wed, Jun 17, 2015 at 3:45 PM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ The issue in your setup is 'ip route add default dev tunl0 via 169.228.66.251 onlink table 44' which should go away if ypu want to reach BGP announced networks.
Why not instead just invoke table 44 when the packet is to or from your
assigned subnet instead of applying it to the entirety of 44/8? What exactly does the "to 44.0.0.0/8" rule do that can't be accomplished by limiting it to "to/from [your subnet]"?
Table 44, where all the tunnle routes reside, has to be used for ALL outgoing 44net destinations, so that the proper tunnel gets selected.
So all packets 'to 44.0.0.0/8' have to go into table 44.
My net is 44.182.21.0/24 If I would use 'to 44.182.21.0/24', only packets having my subnet for destination would reach the tabel. Meaning that outgoing packets e.g. 'to 44.185.1.1' would be processed in the main table via the default route, instead of going to table 44 where they would be send to LZ4NY via the needed tunnel. Again, using 'from 44.182.21.0/24' would direct all packets generated by my subnet to table 44. This would include internet traffic to non-ampr hosts (e.g. 44.182.21.1 to www.google.com), which is not correct, and would skip incoming packets from other 44 subnets, which would be processed by 'main' instead (e.g. 44.185.1.1 to 44.182.21.1).
Marius
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Cory (NQ1E) Sent: Thursday, June 18, 2015 02:18 To: AMPRNet working group Subject: Re: [44net] (no subject)
(Please trim inclusions from previous messages) _______________________________________________ On Wed, Jun 17, 2015 at 3:45 PM, Marius Petrescu marius@yo2loj.ro wrote:
(Please trim inclusions from previous messages) _______________________________________________ The issue in your setup is 'ip route add default dev tunl0 via 169.228.66.251 onlink table 44' which should go away if ypu want to reach BGP announced networks.
Why not instead just invoke table 44 when the packet is to or from your
assigned subnet instead of applying it to the entirety of 44/8? What exactly does the "to 44.0.0.0/8" rule do that can't be accomplished by limiting it to "to/from [your subnet]"?
On Wed, Jun 17, 2015 at 9:11 PM, Marius Petrescu marius@yo2loj.ro wrote:
Table 44, where all the tunnle routes reside, has to be used for ALL outgoing 44net destinations, so that the proper tunnel gets selected.
So all packets 'to 44.0.0.0/8' have to go into table 44.
I'm still hoping you could explain the "why" of that statement. Even if a specific 44 destination has a tunnel, it's only appropriate for your gateway to use it if the source address is within your assigned subnet. Unless I'm missing something, the only reason you should ever be forced to use the tunnels for outbound packets is to prevent them from getting filtered when using your assigned 44 source addresses on them.
using 'from 44.182.21.0/24' would direct all packets generated by my subnet to table 44. This would include internet traffic to non-ampr hosts (e.g. 44.182.21.1 to www.google.com), which is not correct
Well, then I'm really confused as I thought that was intentional. Are you trying to say that hosts on your assigned 44 net are only supposed to be able to communicate with other 44 nets and not any other hosts on the internet?
My understanding of the wiki doc is that it describes how to setup a private network that NATs to the internet on your ISP's address and a separate ham network that uses your assigned 44 IPs. Then the ham network can tunnel traffic between you and other tunneled networks or the general internet by tunneling to the ampr-gw.
Here's a matrix of how I think it's supposed to work:
- PrivateLAN -> InternetHosts = Uses default routing table and NAT
- PrivateLAN -> Assigned44LAN = Routes directly as both subnets direct connected to gw
- PrivateLAN -> OtherIPIPLANs = Should use default routing table and NAT (but likely doesn't due to what seems like a misconfiguration to me)
- Assigned44LAN -> PrivateLAN = Routes directly as both subnets direct connected to gw
- Assigned44LAN -> OtherIPIPLANs = Uses 44 routing table and forwards packets over IPIP tunnel
- Assigned44LAN -> InternetHosts = Uses default 0/0 route on 44 table and IPIP tunnel to ampr-gw for forwarding to internet hosts
- OtherIPIPLANs -> Assigned44LAN = Packets appear on IPIP interface and forwarded to directly connected subnet
- OtherIPIPLANs -> PrivateLAN = Not possible due to non-unique IP space on private LAN
- InternetHosts -> Assigned44LAN = Packets appear on IPIP interface from ampr-gw and forwarded to directly connected subnet
- InternetHosts -> PrivateLAN = Not possible due to non-unique IP space on private LAN
- InternetHosts -> YourGWHost = Packets appear on ISP interface (can then be configured to "port-forward" to LAN using NAT/PAT)
- YourGWHost -> Internet = Uses default route on default table and uses IP of the egress interface (your ISP address)
- YourGWHost -> PrivateLAN = Packets egress on interface directly connected to PrivateLAN with the source IP of that interface
- YourGWHost -> Assigned44LAN = Packets egress on interface directly connected to your 44LAN with the source IP of that interface
- YourGWHost -> BGP-only44Net = Should be treated like any other internet destination and egress the ISP interface; This doesn't work because of the arbitrary "to 44/8 use table 44" rule that doesn't seem to have a valid reason for existing.
If my logic is flawed somehow, please let me know which of the above cases it relates to and hopefully we can clear this up once and for all. :)
Cory,
I see it this way:
- 44 hosts should communicate only with other 44 hosts via tunnels
- to communicate with the internet as originating hosts, they shall use ISP_GW's public IP using masquerade. It makes no sense to add load to ampr-gw unless you really need to land in the internet with a 44 address instead of your GW_IP. Why does this bother you? Google and Facebook doesn't care. And the BGP routed subnets can not be reached this way.
- incoming connections from the internet to 44 come via ampr-gw IPIP and MUST be replied the same way (via IPIP to ampr-gw - if you really want access from the public internet to your 44 IP)
- BGP announced hosts will be reached via NAT/masquerade on the ISP_GW (there's no other way at the moment, unless you're also BGP announced)
- local LAN hosts will reach the internet via NAT/masquerade on the ISP_GW
- local LAN hosts can reach 44 nets if there is a device in the way (router) that can masquerade the local IPs to a 44 net (I would not recommend that).
- YourGWHost -> BGP-only44Net = Should be treated like any other internet
destination and egress the ISP interface; This doesn't work because of the arbitrary "to 44/8 use table 44" rule that doesn't seem to have a valid reason for existing.
It has a valid reason. You still need your 'to 44.0.0.0/8 use table 44' for 44 targets to be dispatched by table 44. What you don't need is the default route in table 44 directing all unknown 44 traffic to the ampr-gw, which is the cause of this behavior. Not the rule, the route in table 44. And for your access from the internet you need a way to get 'from Assigned44LAN to ! 44.0.0.0/8' via the ampr-gw tunnel. One solution would be the one described 2 days earlier, a second custom routing table (for which I use the 'default' table).
Another possibility would be to drop the usage of table 44 and put all routes to table 'main'. Then the rules are not needed for 44/44 traffic. Only the part relating to the reply to incoming non-44 connections via ampr-gw, which need 2 rules to work.
Marius, YO2LOJ
On Thu, Jun 18, 2015 at 12:45 PM, Marius Petrescu marius@yo2loj.ro wrote:
I see it this way:
- 44 hosts should communicate only with other 44 hosts via tunnels
Okay. I'm have to assume that you're speaking about your specific case and not in general. If you want to treat your assigned 44net public IPs as private IPs instead, that's totally up to you and I don't think anyone would/should give you grief about that. I had the impression that we were originally talking about how to configure a gateway in a general sense for most users.
- to communicate with the internet as originating hosts, they shall use
ISP_GW's public IP using masquerade. It makes no sense to add load to ampr-gw unless you really need to land in the internet with a 44 address instead of your GW_IP. Why does this bother you? Google and Facebook doesn't care.
It doesn't bother me at all. It's perfectly reasonable to decide you want to NAT your [Assigned44LAN -> InternetHosts] traffic out your ISP address. I just had no idea that you were trying to use your network that way.
You still need your 'to 44.0.0.0/8 use table 44' for
44 targets to be dispatched by table 44.
No, even with your configuration, you still don't need that rule. Your gateway host will never be an intermediate routing hop between various 44 nets. Therefore, the 'from <Your Assigned 44 net> use table 44' will still make that use-case work just fine.
What you don't need is the default route in table 44 directing all unknown 44 traffic to the ampr-gw, which is the cause of this behavior. Not the rule, the route in table 44.
I have to disagree with you there. The alternate 0/0 default route has a perfectly valid use-case for those who don't want to make their assigned IP space private-only.
And for your access from the internet you need a way to get 'from Assigned44LAN to ! 44.0.0.0/8' via the ampr-gw tunnel. One solution would be the one described 2 days earlier, a second custom routing table (for which I use the 'default' table).
Another possibility would be to drop the usage of table 44 and put all routes to table 'main'. Then the rules are not needed for 44/44 traffic. Only the part relating to the reply to incoming non-44 connections via ampr-gw, which need 2 rules to work.
Wait... I thought you were using NAT/PAT/Masquerade for your [Assigned44LAN -> InternetHosts] traffic??? Why would you then talk about sending those packets to ampr-gw? What exactly are you trying to accomplish with all this added complexity?
Ok. I will not go on wit this.
Just one last comment un that "complexity"...
I need to send replies to external originated traffic to the same network interface they came in. And those come via ampr-gw, no matter the setup. So even if I use NAT for outgoing connections, in case of an connection request from the internet which arrives via ampr-gw, I still need to reply to it via ampr-gw.
This can be acomplished by using connection and routing marks or rules. I use the routing mark approach in an router at the moment, but until a few weeks ago, I used policy routing (rules).
And I accomplish to unload the gateway as much as possible, and depend minimal on it. Of course feel free to do it as you wish.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Cory (NQ1E) Sent: Thursday, June 18, 2015 23:58 To: AMPRNet working group Subject: Re: [44net] (no subject)
And for your access from the internet you need a way to get 'from Assigned44LAN to ! 44.0.0.0/8' via the ampr-gw tunnel. One solution would be the one described 2 days earlier, a second custom routing table (for which I use the 'default' table).
Another possibility would be to drop the usage of table 44 and put all routes to table 'main'. Then the rules are not needed for 44/44 traffic. Only the part relating to the reply to incoming non-44 connections via ampr-gw, which need 2 rules to work.
Wait... I thought you were using NAT/PAT/Masquerade for your [Assigned44LAN -> InternetHosts] traffic??? Why would you then talk about sending those packets to ampr-gw? What exactly are you trying to accomplish with all this added complexity?
-
Cory (NQ1E) -
Marius Petrescu -
Steve L -
Tom Hayward