Hi,
I am looking for help setting up a conditional routing table.
I have my tunnel up and running. I can reach other 44-net host. amrp-ripd is used to fill the routing table.
So far so good, but I would like one of the web-sites (apache httpd vhost) to be reachable from both 44-net and non-44-net. If i check with tcpdump I see traffic coming in when I try to access the web-site (pi8zaa.ampr.org) via the Internet (I used my phone connected to t-mobile network). But it doesn't work because my server routes the replies to my ISP's Gw where they get source filtered.
Basically I want/need traffic that comes in via the tunnel to get answered from the tunnel interface.
I Googled for a solution. Found lots of variant of this http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html but if I understand what is described there correctly, then that is not exactly what I need. Maybe I don't understand iproute2 and its routing table concept correctly. They way I understand it, those examples assume destination routing based on provider subnet, while in my case the destination is on the Internet, and in normal cases should be routed via my ISP except if it came in via the tunnel.
Thanks for any help you can offer.
73 PE1ICQ // Arno
Hi Arno,
I asked the same question about nine months ago. The silence was deafening. ;)
A linux hacker once told me that this sort of thing was possible by using the iptables mangle table to mark the inbound packet based on the inbound interface. Then, somehow, use that to direct the outbound reply. But I don't know if that would really work and I don't have any more details. If you do find a solution, please post it here.
Michael N6MEF
-----Original Message----- From: 44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu [mailto:44net- bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Arno Verhoeven Sent: Friday, December 26, 2014 8:58 AM To: 44net@hamradio.ucsd.edu Subject: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Hi,
I am looking for help setting up a conditional routing table.
I have my tunnel up and running. I can reach other 44-net host. amrp-ripd is used to fill the routing table.
So far so good, but I would like one of the web-sites (apache httpd vhost) to be reachable from both 44-net and non-44-net. If i check with tcpdump I see traffic coming in when I try to access the web-site (pi8zaa.ampr.org) via the Internet (I used my phone connected to t-mobile network). But it doesn't work because my server routes the replies to my ISP's Gw where they get source filtered.
Basically I want/need traffic that comes in via the tunnel to get answered from the tunnel interface.
I Googled for a solution. Found lots of variant of this http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html but if I understand what is described there correctly, then that is not exactly what I need. Maybe I don't understand iproute2 and its routing table concept correctly. They way I understand it, those examples assume destination routing based on provider subnet, while in my case the destination is on the Internet, and in normal cases should be routed via my ISP except if it came in via the tunnel.
Thanks for any help you can offer.
73 PE1ICQ // Arno _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Hello Arno,
You need to do some source routing using ip rules... First, you need 2 ip tables for routing different traffic, and the easiest way is to use existent ones, in this case tables 'main' and 'default'. The main table is used by the normal routing (and make sure ampr-ripd is using that table, else you need to adapt). The default table will be used to route traffic from the internet via tunnel and back.
Let's assume your tunnel interface is called ampr0 and your ampr IP is 44.1.1.1 First you need to bring up the tunnel:
ip tun add ampr0 mode ipip ttl 64 local <your_public_interface_ip>
Then add the following route and rules:
ip route add default via 169.228.66.251 dev ampr0 onlink table default
ip rule add from 44.1.1.1 table default
ip rule add from 44.1.1.1 to 44.0.0.0/8 table main
Next bring up ampr-ripd:
ampr-ripd -s -i ampr0 -p ThePassword
This should do it...
Have fun, 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 Arno Verhoeven Sent: Friday, December 26, 2014 18:58 To: 44net@hamradio.ucsd.edu Subject: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Hi,
I am looking for help setting up a conditional routing table.
I have my tunnel up and running. I can reach other 44-net host. amrp-ripd is used to fill the routing table.
So far so good, but I would like one of the web-sites (apache httpd vhost) to be reachable from both 44-net and non-44-net. If i check with tcpdump I see traffic coming in when I try to access the web-site (pi8zaa.ampr.org) via the Internet (I used my phone connected to t-mobile network). But it doesn't work because my server routes the replies to my ISP's Gw where they get source filtered.
Basically I want/need traffic that comes in via the tunnel to get answered from the tunnel interface.
I Googled for a solution. Found lots of variant of this http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html but if I understand what is described there correctly, then that is not exactly what I need. Maybe I don't understand iproute2 and its routing table concept correctly. They way I understand it, those examples assume destination routing based on provider subnet, while in my case the destination is on the Internet, and in normal cases should be routed via my ISP except if it came in via the tunnel.
Thanks for any help you can offer.
73 PE1ICQ // Arno _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
And just a word of warning...
The rules don't get deleted on interface down.
So take care to add them only once, or delete them in reverse order on interface down.
-----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: Friday, December 26, 2014 20:39 To: 'AMPRNet working group' Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
Then add the following route and rules:
ip route add default via 169.228.66.251 dev ampr0 onlink table default
ip rule add from 44.1.1.1 table default
ip rule add from 44.1.1.1 to 44.0.0.0/8 table main
Mario,
That simply sends 44.x out the tunnel and everything else out the regular interface.
What I believe Arno was asking (and what I was interested in doing) was a different question. Suppose the following: -- Some user out on the public Internet with address 11.22.33.44 -- My system's 44-net address: 44.44.44.44 -- My system's NAT'd external address: 101.102.103.104
Now, suppose the public user connects to 44.44.44.44. His packet comes in via the UCSD gateway and over the AMPRnet link to that gateway to my amprnet interface, 44.44.44.44. The reply should go back out the 44.44.44.44 interface, via the AMPRnet, through the UCSD gateway, and back to the user.
But if the user connects to 101.102.103.104, the reply should go out my regular LAN interface to my local NAT/FW where it's public IP address is re-applied, and it goes direct to the user. So the routing cannot be based on the user's address, but on the interface on which we received the packets. Otherwise, the source address we respond with may be different from the address the user connected to.
Arno - please correct me if I mistook your question. But the above is still something I'd like to be able to do.
Michael N6MEF
-----Original Message----- From: 44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu [mailto:44net- bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Marius Petrescu Sent: Friday, December 26, 2014 10:39 AM To: 'AMPRNet working group' Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Hello Arno,
You need to do some source routing using ip rules... First, you need 2 ip tables for routing different traffic, and the easiest way is to use existent ones, in this case tables 'main' and 'default'. The main table is used by the normal routing (and make sure ampr-ripd is using that table, else you need to adapt). The default table will be used to route traffic from the internet via tunnel and back.
Let's assume your tunnel interface is called ampr0 and your ampr IP is 44.1.1.1 First you need to bring up the tunnel:
ip tun add ampr0 mode ipip ttl 64 local <your_public_interface_ip>
Then add the following route and rules:
ip route add default via 169.228.66.251 dev ampr0 onlink table default
ip rule add from 44.1.1.1 table default
ip rule add from 44.1.1.1 to 44.0.0.0/8 table main
Next bring up ampr-ripd:
ampr-ripd -s -i ampr0 -p ThePassword
This should do it...
Have fun, 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 Arno Verhoeven Sent: Friday, December 26, 2014 18:58 To: 44net@hamradio.ucsd.edu Subject: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Hi,
I am looking for help setting up a conditional routing table.
I have my tunnel up and running. I can reach other 44-net host. amrp-ripd is used to fill the routing table.
So far so good, but I would like one of the web-sites (apache httpd vhost) to be reachable from both 44-net and non-44-net. If i check with tcpdump I see traffic coming in when I try to access the web-site (pi8zaa.ampr.org) via the Internet (I used my phone connected to t-mobile network). But it doesn't work because my server routes the replies to my ISP's Gw where they get source filtered.
Basically I want/need traffic that comes in via the tunnel to get answered from the tunnel interface.
I Googled for a solution. Found lots of variant of this http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html but if I understand what is described there correctly, then that is not exactly what I need. Maybe I don't understand iproute2 and its routing table concept correctly. They way I understand it, those examples assume destination routing based on provider subnet, while in my case the destination is on the Internet, and in normal cases should be routed via my ISP except if it came in via the tunnel.
Thanks for any help you can offer.
73 PE1ICQ // Arno _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
I believe what you’re looking for is covered under this stackexchange article.
http://unix.stackexchange.com/questions/4420/reply-on-same-interface-as-inco... http://unix.stackexchange.com/questions/4420/reply-on-same-interface-as-incoming
Do note though that multiple default routes is somewhat well known to be fiddly, so I hope it works for you.
Nigel
On Dec 26, 2014, at 11:00 AM, Arno Verhoeven pe1icq@vrhvn.nl wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 26-12-14 19:55, Michael E Fox - N6MEF wrote:
Arno - please correct me if I mistook your question. But the above is still something I'd like to be able to do.
You're right. That is exactly what I would like to achieve. _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Those lines of Marius' email will all do that only you you can replace 169.228.66.251 by the Internet address of your local gateway in the Netherlands as Internet traffic from Internet to 44.137.0.0/16 is now handled locally in your Country. Saves some distance and time :-)
Bob VE3TOK
On 14-12-26 02:00 PM, Arno Verhoeven wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 26-12-14 19:55, Michael E Fox - N6MEF wrote:
Arno - please correct me if I mistook your question. But the above is still something I'd like to be able to do.
You're right. That is exactly what I would like to achieve. _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 26-12-14 20:51, Boudewijn (Bob) Tenty wrote:
Those lines of Marius' email will all do that only you you can replace 169.228.66.251 by the Internet address of your local gateway in the Netherlands as Internet traffic from Internet to 44.137.0.0/16 is now handled locally in your Country. Saves some distance and time :-)
That's right. Tunneled traffic for 44.137.24.1 arrived via gw-44-137 and should go out that way :)
On 26-12-14 19:55, Michael E Fox - N6MEF wrote:
Arno - please correct me if I mistook your question. But the above is still something I'd like to be able to do.
You're right. Thai is what I would like to achieve. Just read Marius' mail again, and he might have the solution there.
currently my default routing table is empty.
Marius wrote:
ip route add default via 169.228.66.251 dev ampr0 onlink table default
ip rule add from 44.1.1.1 table default
I'm going to try that and see if that works.
//Arno
No Michael, it doesn't. It does exactly what Arno was asking. Returning answers to requests from the internet via tunnel back to the tunnel.
It will do the following: - regular traffic to the internet will go via the default interface as defined in the 'main' table - traffic from the ampr address to 44.0.0.0/8 will go via tunnel using routes instated there by the ampr-ripd. - traffic from your ampr address to anything else (meaning the internet) will go to the default route in the 'default' table, in this case the ampr-gw tunnel endpoint.
It works well on my server. Try to ping/traceroute yo2tm.ampr.org from a public IP and see for yourself. If you like I can activate external acces so you can check (I don't admit anything else except icmp and the moment).
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 Michael E Fox - N6MEF Sent: Friday, December 26, 2014 20:56 To: 'AMPRNet working group' Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Mario,
That simply sends 44.x out the tunnel and everything else out the regular interface.
What I believe Arno was asking (and what I was interested in doing) was a different question. Suppose the following: -- Some user out on the public Internet with address 11.22.33.44 -- My system's 44-net address: 44.44.44.44 -- My system's NAT'd external address: 101.102.103.104
Now, suppose the public user connects to 44.44.44.44. His packet comes in via the UCSD gateway and over the AMPRnet link to that gateway to my amprnet interface, 44.44.44.44. The reply should go back out the 44.44.44.44 interface, via the AMPRnet, through the UCSD gateway, and back to the user.
But if the user connects to 101.102.103.104, the reply should go out my regular LAN interface to my local NAT/FW where it's public IP address is re-applied, and it goes direct to the user. So the routing cannot be based on the user's address, but on the interface on which we received the packets. Otherwise, the source address we respond with may be different from the address the user connected to.
Arno - please correct me if I mistook your question. But the above is still something I'd like to be able to do.
Michael N6MEF
-----Original Message----- From: 44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu [mailto:44net- bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Marius Petrescu Sent: Friday, December 26, 2014 10:39 AM To: 'AMPRNet working group' Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Hello Arno,
You need to do some source routing using ip rules... First, you need 2 ip tables for routing different traffic, and the easiest way is to use existent ones, in this case tables 'main' and 'default'. The main table is used by the normal routing (and make sure ampr-ripd is using that table, else you need to adapt). The default table will be used to route traffic from the internet via tunnel and back.
Let's assume your tunnel interface is called ampr0 and your ampr IP is 44.1.1.1 First you need to bring up the tunnel:
ip tun add ampr0 mode ipip ttl 64 local <your_public_interface_ip>
Then add the following route and rules:
ip route add default via 169.228.66.251 dev ampr0 onlink table default
ip rule add from 44.1.1.1 table default
ip rule add from 44.1.1.1 to 44.0.0.0/8 table main
Next bring up ampr-ripd:
ampr-ripd -s -i ampr0 -p ThePassword
This should do it...
Have fun, 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 Arno Verhoeven Sent: Friday, December 26, 2014 18:58 To: 44net@hamradio.ucsd.edu Subject: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Hi,
I am looking for help setting up a conditional routing table.
I have my tunnel up and running. I can reach other 44-net host. amrp-ripd is used to fill the routing table.
So far so good, but I would like one of the web-sites (apache httpd vhost) to be reachable from both 44-net and non-44-net. If i check with tcpdump I see traffic coming in when I try to access the web-site (pi8zaa.ampr.org) via the Internet (I used my phone connected to t-mobile network). But it doesn't work because my server routes the replies to my ISP's Gw where they get source filtered.
Basically I want/need traffic that comes in via the tunnel to get answered from the tunnel interface.
I Googled for a solution. Found lots of variant of this http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html but if I understand what is described there correctly, then that is not exactly what I need. Maybe I don't understand iproute2 and its routing table concept correctly. They way I understand it, those examples assume destination routing based on provider subnet, while in my case the destination is on the Internet, and in normal cases should be routed via my ISP except if it came in via the tunnel.
Thanks for any help you can offer.
73 PE1ICQ // Arno _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
O.K. Thanks. I'd swear I tried this before and it didn't work. I'll give it another go.
Michael N6MEF
-----Original Message----- From: 44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu [mailto:44net- bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Marius Petrescu Sent: Friday, December 26, 2014 11:08 AM To: 'AMPRNet working group' Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ No Michael, it doesn't. It does exactly what Arno was asking. Returning answers to requests from the internet via tunnel back to the tunnel.
It will do the following:
- regular traffic to the internet will go via the default interface as
defined in the 'main' table
- traffic from the ampr address to 44.0.0.0/8 will go via tunnel using
routes instated there by the ampr-ripd.
- traffic from your ampr address to anything else (meaning the internet)
will go to the default route in the 'default' table, in this case the ampr-gw tunnel endpoint.
It works well on my server. Try to ping/traceroute yo2tm.ampr.org from a public IP and see for yourself. If you like I can activate external acces so you can check (I don't admit anything else except icmp and the moment).
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 Michael E Fox - N6MEF Sent: Friday, December 26, 2014 20:56 To: 'AMPRNet working group' Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Mario,
That simply sends 44.x out the tunnel and everything else out the regular interface.
What I believe Arno was asking (and what I was interested in doing) was a different question. Suppose the following: -- Some user out on the public Internet with address 11.22.33.44 -- My system's 44-net address: 44.44.44.44 -- My system's NAT'd external address: 101.102.103.104
Now, suppose the public user connects to 44.44.44.44. His packet comes in via the UCSD gateway and over the AMPRnet link to that gateway to my amprnet interface, 44.44.44.44. The reply should go back out the 44.44.44.44 interface, via the AMPRnet, through the UCSD gateway, and back to the user.
But if the user connects to 101.102.103.104, the reply should go out my regular LAN interface to my local NAT/FW where it's public IP address is re-applied, and it goes direct to the user. So the routing cannot be based on the user's address, but on the interface on which we received the packets. Otherwise, the source address we respond with may be different from the address the user connected to.
Arno - please correct me if I mistook your question. But the above is still something I'd like to be able to do.
Michael N6MEF
-----Original Message----- From: 44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu [mailto:44net- bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Marius Petrescu Sent: Friday, December 26, 2014 10:39 AM To: 'AMPRNet working group' Subject: Re: [44net] How to make traffic coming in on the tunnel
interface
get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Hello Arno,
You need to do some source routing using ip rules... First, you need 2 ip tables for routing different traffic, and the
easiest
way is to use existent ones, in this case tables 'main' and 'default'. The main table is used by the normal routing (and make sure ampr-ripd is using that table, else you need to adapt). The default table will be used to route traffic from the internet via tunnel and back.
Let's assume your tunnel interface is called ampr0 and your ampr IP is 44.1.1.1 First you need to bring up the tunnel:
ip tun add ampr0 mode ipip ttl 64 local <your_public_interface_ip>
Then add the following route and rules:
ip route add default via 169.228.66.251 dev ampr0 onlink table default
ip rule add from 44.1.1.1 table default
ip rule add from 44.1.1.1 to 44.0.0.0/8 table main
Next bring up ampr-ripd:
ampr-ripd -s -i ampr0 -p ThePassword
This should do it...
Have fun, 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 Arno Verhoeven Sent: Friday, December 26, 2014 18:58 To: 44net@hamradio.ucsd.edu Subject: [44net] How to make traffic coming in on the tunnel interface
get
answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Hi,
I am looking for help setting up a conditional routing table.
I have my tunnel up and running. I can reach other 44-net host. amrp-ripd is used to fill the routing table.
So far so good, but I would like one of the web-sites (apache httpd vhost) to be reachable from both 44-net and non-44-net. If i check with tcpdump I see traffic coming in when I try to access the web-site (pi8zaa.ampr.org) via the Internet (I used my phone connected to t-mobile network). But it doesn't work because my server routes the replies to my ISP's Gw where they get source filtered.
Basically I want/need traffic that comes in via the tunnel to get answered from the tunnel interface.
I Googled for a solution. Found lots of variant of this http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html but if I understand what is described there correctly, then that is not exactly what I need. Maybe I don't understand iproute2 and its routing table concept correctly. They way I understand it, those examples assume destination routing based on provider subnet, while in my case the destination is on the Internet, and in normal cases should be routed via my ISP except if it came in via the tunnel.
Thanks for any help you can offer.
73 PE1ICQ // Arno _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Just to clarify this: The unterstanding on how a full mesh works is wrong.
Now, suppose the public user connects to 44.44.44.44. His packet comes in via the UCSD gateway and over the AMPRnet link to that gateway to my
amprnet
interface, 44.44.44.44. The reply should go back out the 44.44.44.44 interface, via the AMPRnet, through the UCSD gateway, and back to the
user.
No. It doesn't. If the user connects from 44.44.44.44 his packet comes directly via the IPIP tunnel, not via the UCSD gateway. And that user will have an encap route set up by the routing daemon pointing back directly to his machine. The answer will be IPIP encapsulated end sent back directly. The UCSD gateway is not involved in this case.
But if the user connects to 101.102.103.104, the reply should go out my regular LAN interface to my local NAT/FW where it's public IP address is re-applied, and it goes direct to the user.
This is correct, as long as the user connects to the gateways public IP. And routing is correct in this case.
And the third case Arno was talking about: The user with a regular IP connects to an ampr IP address. Then it will be routed via UCSD gateway and sent IPIP encapsulated to the gateway IP. It is decapsulated and will contain packets from 1.2.3.4 (the users public ip) to let's say, 44.1.1.1 (our ampr address). The answer has to go back via that tunnel at UCSD, from 44.1.1.1 to 1.2.3.4, IPIP encapsulated from our public IP to the UCSD gateway.
Marius, YO2LOJ
-----Original Message----- Just to clarify this: The unterstanding on how a full mesh works is wrong.
Now, suppose the public user connects to 44.44.44.44. His packet comes
in
via the UCSD gateway and over the AMPRnet link to that gateway to my
amprnet
interface, 44.44.44.44. The reply should go back out the 44.44.44.44 interface, via the AMPRnet, through the UCSD gateway, and back to the
user.
No. It doesn't. If the user connects from 44.44.44.44 his packet comes
Not from, to. The user's (from) IP address was given as 11.22.33.44. See previous message.
Michael N6MEF
Ok Michael, I just misread that post. Sorry. You are right. And the rules do exactly that. Traffic originating on the ampr interface with destination outside the ampr network will go to table 'default', and that one will have a default route via the UCSD gateway.
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 Michael E Fox - N6MEF Sent: Friday, December 26, 2014 21:48 To: 'AMPRNet working group' Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________
-----Original Message----- Just to clarify this: The unterstanding on how a full mesh works is wrong.
Now, suppose the public user connects to 44.44.44.44. His packet comes
in
via the UCSD gateway and over the AMPRnet link to that gateway to my
amprnet
interface, 44.44.44.44. The reply should go back out the 44.44.44.44 interface, via the AMPRnet, through the UCSD gateway, and back to the
user.
No. It doesn't. If the user connects from 44.44.44.44 his packet comes
Not from, to. The user's (from) IP address was given as 11.22.33.44. See previous message.
Michael N6MEF
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Mario,
I guess I'm still missing something.
In your suggestion below, 44.1.1.1 is the address assigned to the AMPRnet tunnel on the linux box. But once the inbound packet arrives there, it must still traverse another tunnel, tun0, to JNOS (in my case). Then JNOS responds. But the source address is JNOS's address. Linux is just acting as a multi-interface router. So an "ip rule" based on a linux interface as the "from" address doesn't apply.
Or, does your solution assume that linux is also NAT'ing the traffic, converting the source address of the outbound back from the JNOS address to the 44.1.1.1 address, after which the ip rule gets applied. (I'm not sure of the processing order. I'd have to get out my iptables book!)
Thanks, Michael N6MEF
You need to do some source routing using ip rules... First, you need 2 ip tables for routing different traffic, and the
easiest
way is to use existent ones, in this case tables 'main' and 'default'. The main table is used by the normal routing (and make sure ampr-ripd is using that table, else you need to adapt). The default table will be used to route traffic from the internet via tunnel and back.
Let's assume your tunnel interface is called ampr0 and your ampr IP is 44.1.1.1 First you need to bring up the tunnel:
ip tun add ampr0 mode ipip ttl 64 local <your_public_interface_ip>
Then add the following route and rules:
ip route add default via 169.228.66.251 dev ampr0 onlink table default
ip rule add from 44.1.1.1 table default
ip rule add from 44.1.1.1 to 44.0.0.0/8 table main
Next bring up ampr-ripd:
ampr-ripd -s -i ampr0 -p ThePassword
This should do it...
Have fun, 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 Arno Verhoeven Sent: Friday, December 26, 2014 18:58 To: 44net@hamradio.ucsd.edu Subject: [44net] How to make traffic coming in on the tunnel interface
get
answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Hi,
I am looking for help setting up a conditional routing table.
I have my tunnel up and running. I can reach other 44-net host. amrp-ripd is used to fill the routing table.
So far so good, but I would like one of the web-sites (apache httpd vhost) to be reachable from both 44-net and non-44-net. If i check with tcpdump I see traffic coming in when I try to access the web-site (pi8zaa.ampr.org) via the Internet (I used my phone connected to t-mobile network). But it doesn't work because my server routes the replies to my ISP's Gw where they get source filtered.
Basically I want/need traffic that comes in via the tunnel to get answered from the tunnel interface.
I Googled for a solution. Found lots of variant of this http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html but if I understand what is described there correctly, then that is not exactly what I need. Maybe I don't understand iproute2 and its routing table concept correctly. They way I understand it, those examples assume destination routing based on provider subnet, while in my case the destination is on the Internet, and in normal cases should be routed via my ISP except if it came in via the tunnel.
Thanks for any help you can offer.
73 PE1ICQ // Arno _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Yes, my solution assumes that 44.1.1.1 is assigned to the tunnel and that all services run locally. So let's get this also up and running :-)
But I need some data: do you have a single IP assigned, or a subnet? In other words, is there a possibility to to assign one ampr address to the tunnel (it is ok even if it is not registered in the dns) or do you need to use a single IP address only on the JNOS?
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Michael E Fox - N6MEF Sent: Saturday, December 27, 2014 22:20 To: 'AMPRNet working group' Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Mario,
I guess I'm still missing something.
In your suggestion below, 44.1.1.1 is the address assigned to the AMPRnet tunnel on the linux box. But once the inbound packet arrives there, it must still traverse another tunnel, tun0, to JNOS (in my case). Then JNOS responds. But the source address is JNOS's address. Linux is just acting as a multi-interface router. So an "ip rule" based on a linux interface as the "from" address doesn't apply.
Or, does your solution assume that linux is also NAT'ing the traffic, converting the source address of the outbound back from the JNOS address to the 44.1.1.1 address, after which the ip rule gets applied. (I'm not sure of the processing order. I'd have to get out my iptables book!)
Thanks, Michael N6MEF
Thanks, Marius.
I think I can take it from here.
Michael
-----Original Message-----
But I need some data: do you have a single IP assigned, or a subnet? In other words, is there a possibility to to assign one ampr address to the tunnel (it is ok even if it is not registered in the dns) or do you need to use a single IP address only on the JNOS?
On 26-12-14 19:38, Marius Petrescu wrote:
First you need to bring up the tunnel:
ip tun add ampr0 mode ipip ttl 64 local <your_public_interface_ip>
Why should the tunnel interface have the same ip address as the wan interface?
I gave it a 44-net address (44.137.24.1).
In the command ip tun add ampr0 mode ipip ttl 64 local <your_public_interface_ip> The address is not the tunnel address. It is the address on witch it listens for incoming IPIP packets, and on whitch it sends out the encapsulated traffic. The IP address for that interface is assigned by ifconfig ot other tools/scripts.
So you have an eth0 interface (just as an example) which is your uplink interface with a public IP, let's say 1.2.3.4. Then you create the tunnel on that interface: ip tun add ampr0 mode ipip ttl 64 local 1.2.3.4
and configure that interface (I missed that tstep in my example):
ifconfig ampr0 44.1.1.1 netmask 255.255.255.0 up
So you will get an interface called ampr0 with IP 44.1.1.1 and network 44.1.1.0/24 with tunnel endpoint 1.2.3.4
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Arno Verhoeven Sent: Friday, December 26, 2014 21:24 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________
On 26-12-14 19:38, Marius Petrescu wrote:
First you need to bring up the tunnel:
ip tun add ampr0 mode ipip ttl 64 local <your_public_interface_ip>
Why should the tunnel interface have the same ip address as the wan interface?
I gave it a 44-net address (44.137.24.1).
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
For test/tracing purposes, I opened the dxspider port on yo2tm.ampr.org for access from the internet (44.182.21.1 port 8873). The setup is exactly the one I described.
Marius, YO2LOJ
On 26-12-14 19:38, Marius Petrescu wrote:
You need to do some source routing using ip rules... First, you need 2 ip tables for routing different traffic, and the easiest way is to use existent ones, in this case tables 'main' and 'default'. The main table is used by the normal routing (and make sure ampr-ripd is using that table, else you need to adapt). The default table will be used to route traffic from the internet via tunnel and back.
Let's assume your tunnel interface is called ampr0 and your ampr IP is 44.1.1.1 First you need to bring up the tunnel:
ip tun add ampr0 mode ipip ttl 64 local <your_public_interface_ip>
Then add the following route and rules:
ip route add default via 169.228.66.251 dev ampr0 onlink table default
ip rule add from 44.1.1.1 table default
ip rule add from 44.1.1.1 to 44.0.0.0/8 table main
Next bring up ampr-ripd:
ampr-ripd -s -i ampr0 -p ThePassword
This should do it...
Have fun,
The fun can begin. It works. Thanks.
Because 44.137.0.0/16 is announced on the internet with it's own Gw, I do not have ucsd as default gw for the tunnel.
This is my config script.
/sbin/ip tunnel add tun1 mode ipip local 88.159.160.228 ttl 64 /sbin/ifconfig tun1 44.137.24.1/32 multicast up /sbin/ip route add default via 213.222.29.194 dev tun1 onlink table default /sbin/ip rule add from 44.137.24.1 table default /sbin/ip rule add from 44.137.24.1 to 44.0.0.0/8 table main /usr/sbin/ampr-ripd -s -i tun1 -a 44.137.24.1,44.137.27.112/28 -p ThePassword
Next I need to tweak some firewall rules, because I see some domain service requests from local 192.168.x.x hosts on the tunnel.
Thanks guys!
//Arno
On 2014-12-26 17:58, Arno Verhoeven wrote: [..]
But it doesn't work because my server routes the replies to my ISP's Gw where they get source filtered.
Good ISP they should filter based on source addresses :)
And you partially have your answer in that sentence too: source based routing
Check for instance: http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.simple.html
Which is a simple example.
(In IPv6 one can do it simpler with the 'src' attribute, but unfortunately they did not bring that to IPv4...)
Greets, Jeroen
On 26-12-14 19:38, Jeroen Massar wrote:
Good ISP they should filter based on source addresses :)
Yes the should.
And you partially have your answer in that sentence too: source based routing
Check for instance: http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.simple.html
I looked at that one, but don;t think that that is it.
Greetings;
On Fri, 2014-12-26 at 17:58 +0100, Arno Verhoeven wrote:
I am looking for help setting up a conditional routing table.
I have my tunnel up and running. I can reach other 44-net host. amrp-ripd is used to fill the routing table.
So far so good, but I would like one of the web-sites (apache httpd vhost) to be reachable from both 44-net and non-44-net.
You need to do policy routing via IP RULES.
http://n1uro.ampr.org/linuxconf/dotun.html Explains it and also gives you a working script you may use that will do what you need it to do.
Your apache server must be listening on 2 IP addresses.
1 could be a private IP address, request from commercial Internet get destination NATted to that private IP, the other could be a 44net IP address.
The good thing about most networks daemons (like apache) is that they will respond from the IP address that has received the request, so you can use source based routing to distinguish between commercial Internet and 44net/AMPR outbound traffic.
Packets sourced from your private IP address are replies to requests from the commercial Internet and your can have them routed normally.
Packets sourced from your 44net/AMPR address are replies to requests from 44net/AMPR.
From here you can use http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.simple.html to set it all up.
In case you are using 1 single IP address on apache, there is no way to accomplish what you want to do, you can only do destination based routing in that case.
73 de Marc
On 2014-12-26 17:58, Arno Verhoeven wrote:
(Please trim inclusions from previous messages) _______________________________________________ Hi,
I am looking for help setting up a conditional routing table.
I have my tunnel up and running. I can reach other 44-net host. amrp-ripd is used to fill the routing table.
So far so good, but I would like one of the web-sites (apache httpd vhost) to be reachable from both 44-net and non-44-net. If i check with tcpdump I see traffic coming in when I try to access the web-site (pi8zaa.ampr.org) via the Internet (I used my phone connected to t-mobile network). But it doesn't work because my server routes the replies to my ISP's Gw where they get source filtered.
Basically I want/need traffic that comes in via the tunnel to get answered from the tunnel interface.
I Googled for a solution. Found lots of variant of this http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html but if I understand what is described there correctly, then that is not exactly what I need. Maybe I don't understand iproute2 and its routing table concept correctly. They way I understand it, those examples assume destination routing based on provider subnet, while in my case the destination is on the Internet, and in normal cases should be routed via my ISP except if it came in via the tunnel.
Thanks for any help you can offer.
73 PE1ICQ // Arno _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Hi Marc,
You are right. The good part is that all Linux networking follows this rule, and this is enforced by the kernel. Because a socket is set up with well defined endpoints before any network traffic can take place. So, as long as a software component uses plain kernel based networking, and doesn't do any "smart" networking stunts, source routing can be applied to ensure proper return paths based on source and destination.
@Arno: Congratulations. Nice to hear that.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Marc, LX1DUC Sent: Saturday, December 27, 2014 00:29 To: AMPRNet working group Cc: 44net-bounces+lx1duc=laru.lu@hamradio.ucsd.edu Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Your apache server must be listening on 2 IP addresses.
1 could be a private IP address, request from commercial Internet get destination NATted to that private IP, the other could be a 44net IP address.
The good thing about most networks daemons (like apache) is that they will respond from the IP address that has received the request, so you can use source based routing to distinguish between commercial Internet and 44net/AMPR outbound traffic.
On 27-12-14 11:09, Marius Petrescu wrote:
@Arno: Congratulations. Nice to hear that.
Thanks, but I'm not completely there yet. For some reason I lost ampr-ripd functionality. ampr-ripd is running, but does not actually set any routes.
with 'tcpdump -vvv -s0 -n proto ipencap' I see encapsulated ripv2 traffic arriving at eth0. But when I check with 'tcpdump -i tun1 -vv' I see none of those on the tunnel interface.
It worked before, and I can figure out why it doesn't work now....
Hello Arno,
You could try adding the -r option to ampr-ripd, so it will use raw sockets instead of multicast sockets. This was added to overcome a problem on new ubuntu distributions with 3.x kernels, which didn't work the traditional way on multicast in some cases. The functionality is not impacted by any means by that (I even think to make this the default mode...).
On observation: using 44.137.27.112/28 in the -a option has no effect, since 44.137.27.112/28 is not broadcasted by UCSD. ampr-ripd evaluates only EXACT entries in the encap, not IP ranges list. But this should be of no importance for the moment.
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 Arno Verhoeven Sent: Saturday, December 27, 2014 12:19 To: AMPRNet working group Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________
On 27-12-14 11:09, Marius Petrescu wrote:
@Arno: Congratulations. Nice to hear that.
Thanks, but I'm not completely there yet. For some reason I lost ampr-ripd functionality. ampr-ripd is running, but does not actually set any routes.
with 'tcpdump -vvv -s0 -n proto ipencap' I see encapsulated ripv2 traffic arriving at eth0. But when I check with 'tcpdump -i tun1 -vv' I see none of those on the tunnel interface.
It worked before, and I can figure out why it doesn't work now....
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 27-12-14 11:36, Marius Petrescu wrote:
You could try adding the -r option to ampr-ripd, so it will use raw sockets instead of multicast sockets. This was added to overcome a problem on new ubuntu distributions with 3.x kernels, which didn't work the traditional way on multicast in some cases. The functionality is not impacted by any means by that (I even think to make this the default mode...).
I'm running Slackware but also with a 3.x kernel. I'll try the -r option but do not have high hopes because I do not even see the rip broadcasts appearing on the tunnel interface with tcpdump.
It appears it works fine if I create the tunnel with:
/sbin/ifconfig tunl0 44.137.24.1 netmask 255.255.255.255 up /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 metric 128 tunl0 /sbin/route add -net 44.0.0.0/8 gw $GATEWAY tunl0 /sbin/route del default tunl0
But then I cannot set ttl to 64 (for traceroute).
it does not work when I create the tunnel with:
/sbin/ip tunnel add ampr0 mode ipip local 88.159.160.228 ttl 64 /sbin/ifconfig ampr0 44.137.24.1/32 multicast up /sbin/ip route add default via 213.222.29.194 dev ampr0 onlink table default /sbin/ip rule add from 44.137.24.1 table default /sbin/ip rule add from 44.137.24.1 to 44.0.0.0/8 table main
Strangely the static routes set above work. But rip broadcasts don't come through. (I have changed the interface name accordingly when starting ampr-ripd. i.e ampr0 instead of tunl0)
My firewall script does have the lines:
/usr/sbin/iptables -A INPUT -p ipip -j ACCEPT /usr/sbin/iptables -A INPUT -p udp --dport 520 -j ACCEPT
On observation: using 44.137.27.112/28 in the -a option has no effect, since 44.137.27.112/28 is not broadcasted by UCSD. ampr-ripd evaluates only EXACT entries in the encap, not IP ranges list. But this should be of no importance for the moment.
I know. I removed 44.137.27.112/28 from my gateway on the portal a day or two ago. I first want to get get it working for the single host.
Can't you just do an "ip change tunl0 ttl 64" afterwards?
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Arno Verhoeven Sent: Saturday, December 27, 2014 12:59 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
It appears it works fine if I create the tunnel with:
/sbin/ifconfig tunl0 44.137.24.1 netmask 255.255.255.255 up /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 metric 128 tunl0 /sbin/route add -net 44.0.0.0/8 gw $GATEWAY tunl0 /sbin/route del default tunl0
But then I cannot set ttl to 64 (for traceroute).
On Sat, 2014-12-27 at 13:21 +0200, Marius Petrescu wrote:
Can't you just do an "ip change tunl0 ttl 64" afterwards?
Try this:
/sbin/ip tunnel change tunl0 mode ipip ttl 64 pmtudisc
Ok. now this was a bad response. Actually the problem is at the tunnel interface, not at ripd...
Check your firewall setting so that you accept proto 4/IPIP from your rip2 broadcast source as you can see it in yout tcpdump trace.
-----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: Saturday, December 27, 2014 12:36 To: 'AMPRNet working group' Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________ Hello Arno,
You could try adding the -r option to ampr-ripd, so it will use raw sockets instead of multicast sockets. This was added to overcome a problem on new ubuntu distributions with 3.x kernels, which didn't work the traditional way on multicast in some cases. The functionality is not impacted by any means by that (I even think to make this the default mode...).
On observation: using 44.137.27.112/28 in the -a option has no effect, since 44.137.27.112/28 is not broadcasted by UCSD. ampr-ripd evaluates only EXACT entries in the encap, not IP ranges list. But this should be of no importance for the moment.
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 Arno Verhoeven Sent: Saturday, December 27, 2014 12:19 To: AMPRNet working group Subject: Re: [44net] How to make traffic coming in on the tunnel interface get answered from that interface?
(Please trim inclusions from previous messages) _______________________________________________
On 27-12-14 11:09, Marius Petrescu wrote:
@Arno: Congratulations. Nice to hear that.
Thanks, but I'm not completely there yet. For some reason I lost ampr-ripd functionality. ampr-ripd is running, but does not actually set any routes.
with 'tcpdump -vvv -s0 -n proto ipencap' I see encapsulated ripv2 traffic arriving at eth0. But when I check with 'tcpdump -i tun1 -vv' I see none of those on the tunnel interface.
It worked before, and I can figure out why it doesn't work now....
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 27-12-14 12:00, Marius Petrescu wrote:
Actually the problem is at the tunnel interface, not at ripd...
Check your firewall setting so that you accept proto 4/IPIP from your rip2 broadcast source as you can see it in yout tcpdump trace.
Right. the firewall was the problem. I had gone over the firewall script over and over again, to look for the problem. Couldn't find a problem. I was convinced that the problem must be somewhere else, e.g. creation of the tunnel interface, of a kernel thing, or whatever.
I did not dare completely disabling the firewall because the server is doing a lot of other things apart from being the ampr Gw. But when I finally disabled the firewall anyway, and everything related to the tunnel worked.
The INPUT policy was set to DROP and I already had these 2 lines in the firewall script:
/usr/sbin/iptables -A INPUT -p ipip -j ACCEPT /usr/sbin/iptables -A INPUT -p udp --dport 520 -j ACCEPT
But apparently that was not enough. It all worked after adding this two lines also.
/usr/sbin/iptables -A INPUT -s 169.228.66.251 -j ACCEPT # amprgw.sysnet.ucsd.edu /usr/sbin/iptables -A INPUT -s 213.222.29.194 -j ACCEPT # gw-44-137-ext.ampr.org
It really helps to have this mailinglist. Of course because of the responses, but it also helps to yourself to get your thoughts straight while describing the problem.
Thanks Marius and others for all your help.
73 PE1ICQ //Arno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Well the issue lies with
/usr/sbin/iptables -A INPUT -p ipip -j ACCEPT
"-p ipip" does NOT do what you think it does.
It allows protocol 94.
What you actually want to do is:
/usr/sbin/iptables -A INPUT -p ipencap -j ACCEPT
or to be safe use:
/usr/sbin/iptables -A INPUT -p 4 -j ACCEPT
73 de Marc
On 27/12/2014 13:55, Arno Verhoeven wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 27-12-14 12:00, Marius Petrescu wrote:
Actually the problem is at the tunnel interface, not at ripd...
Check your firewall setting so that you accept proto 4/IPIP from your rip2 broadcast source as you can see it in yout tcpdump trace.
Right. the firewall was the problem. I had gone over the firewall script over and over again, to look for the problem. Couldn't find a problem. I was convinced that the problem must be somewhere else, e.g. creation of the tunnel interface, of a kernel thing, or whatever.
I did not dare completely disabling the firewall because the server is doing a lot of other things apart from being the ampr Gw. But when I finally disabled the firewall anyway, and everything related to the tunnel worked.
The INPUT policy was set to DROP and I already had these 2 lines in the firewall script:
/usr/sbin/iptables -A INPUT -p ipip -j ACCEPT /usr/sbin/iptables -A INPUT -p udp --dport 520 -j ACCEPT
But apparently that was not enough. It all worked after adding this two lines also.
/usr/sbin/iptables -A INPUT -s 169.228.66.251 -j ACCEPT # amprgw.sysnet.ucsd.edu /usr/sbin/iptables -A INPUT -s 213.222.29.194 -j ACCEPT # gw-44-137-ext.ampr.org
It really helps to have this mailinglist. Of course because of the responses, but it also helps to yourself to get your thoughts straight while describing the problem.
Thanks Marius and others for all your help.
73 PE1ICQ //Arno
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 27-12-14 14:09, Marc, LX1DUC wrote:
Well the issue lies with
/usr/sbin/iptables -A INPUT -p ipip -j ACCEPT
"-p ipip" does NOT do what you think it does.
It allows protocol 94.
What you actually want to do is:
/usr/sbin/iptables -A INPUT -p ipencap -j ACCEPT
or to be safe use:
/usr/sbin/iptables -A INPUT -p 4 -j ACCEPT
Thanks marc, this is a valuable lesson. It has cost me hours and hours trying to figure it out.
-
Arno Verhoeven -
Boudewijn (Bob) Tenty -
Brian -
Jeroen Massar -
Marc, LX1DUC -
Marius Petrescu -
Michael E Fox - N6MEF -
Nigel Vander Houwen