26 Dec
2014
26 Dec
'14
10:58 a.m.
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
26 Dec
26 Dec
12:30 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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(a)hamradio.ucsd.edu [mailto:44net-
bounces+n6mef=mefox.org(a)hamradio.ucsd.edu] On Behalf Of Arno Verhoeven
Sent: Friday, December 26, 2014 8:58 AM
To: 44net(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
12:38 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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(a)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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
12:44 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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(a)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
12:55 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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(a)hamradio.ucsd.edu [mailto:44net-
bounces+n6mef=mefox.org(a)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(a)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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
1:04 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
I believe what you’re looking for is covered under this stackexchange article.
http://unix.stackexchange.com/questions/4420/reply-on-same-interface-as-inc…
<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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net 
1:51 p.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
2:02 p.m.
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 :)
1:06 p.m.
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
1:07 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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(a)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(a)hamradio.ucsd.edu [mailto:44net-
bounces+n6mef=mefox.org(a)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(a)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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
1:15 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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(a)hamradio.ucsd.edu [mailto:44net-
bounces+n6mef=mefox.org(a)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(a)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(a)hamradio.ucsd.edu [mailto:44net-
bounces+n6mef=mefox.org(a)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(a)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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
1:19 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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
1:47 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
-----Original Message-----
Just to clarify this: The unterstanding on how a full mesh works is wrong.
Not from, to. The user's (from) IP address was given as 11.22.33.44. See
previous message.
Michael
N6MEF
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
1:52 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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(a)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.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
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
27 Dec
27 Dec
2:19 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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(a)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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
2:47 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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(a)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
2:54 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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?
26 Dec
26 Dec
1:24 p.m.
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).
1:33 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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(a)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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
1:40 p.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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
2:40 p.m.
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
12:38 p.m.
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
1:07 p.m.
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.
2:50 p.m.
New subject: Tunnel route script
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.
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
4:28 p.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
--
Marc, LX1DUC
--
www.laru.lu - Luxembourg Amateur Radio Union
www.emcomm.services - Emergency Communication
www.ham-dmr.lu - DMR Infos for HAMs
27 Dec
27 Dec
4:09 a.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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(a)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(a)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.
4:19 a.m.
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....
4:36 a.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
4:58 a.m.
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.
5:21 a.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
Can't you just do an "ip change tunl0 ttl 64" afterwards?
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)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(a)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).
12:01 p.m.
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
--
If Microsoft intended Windows to be for ham usage,
they would have incorporated our protocols into their kernel.
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
5 a.m.
New subject: How to make traffic coming in on the tunnel interface get answered from that interface?
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(a)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(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
6:55 a.m.
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
7:09 a.m.
-----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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net -----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJUnq9tAAoJEHFIN1T8ZA8vgPsP/iMIFP5MZ3+eFbZekZ1tt67M
IkmUeUdL2ZdO18foZZ/lBHbjQODO4K6dLpDhEu3zHHHGr0n0RVksPZuo6sGddHax
35DQL8qIrqHKHdCwWTsDGDaPvqPHARjeHql/cN82EtFlAw3I9Y1N0FUvHZPzImo4
7DkXGSpLAr9d1/J3iir1upTShNwx79m0fcJ2dlL/G+B9ph4G4Zmrv4+/5Pzmwu7P
HsC1hug5bpc0QWimMI0BxaYzVZKl4c5EOTgw3IJs55X4VFF0BiFywy6H/gbgGhUt
1uUZDq4tAU8F+gcuXKOoM+1YGMafJfb9WENHRjdyItaQE0uB7LASzgqFHgCtMrWA
G7rEEq3Tzn/5ZCUNOnIuohR0MyvayUAb8ECGaZLPq2feK6ccoHxWcy8AoL5aT2k6
Mce42srG0JiI0R9PbI/MbTpa3NEXfyxo+tcxjS0DpuFuDY4/E1CM4xCJeNCpgoPz
c/S+NiLoAMhVAUSthU3jQzXvpBPWpwDV6dVMrB8jP32E8Zq8LKnq9XL7RySu9sSe
VkrwkyUa+0K1M5q2LA23Z2kx/OK9E1jS+aOFqsYI4oRrfEl59HdHCCTP31/csTrX
nMppB5WgZWDajAu//whts6w8giEeN0xZFyF/C+3Hbsv4EL+Cc1feCOO3riFxorHY
HbZZYB09RSoCMVtnJpm1
=TR4V
-----END PGP SIGNATURE-----
7:13 a.m.
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.
3619
days inactive
3620
days old
36 comments
8 participants
participants (8)
-
Arno Verhoeven -
Boudewijn (Bob) Tenty -
Brian -
Jeroen Massar -
Marc, LX1DUC -
Marius Petrescu -
Michael E Fox - N6MEF -
Nigel Vander Houwen