Route packets from an interface to another

Route packets from an interface to another

[Jonathan]

Hello,
I have the following interface configuration on two boxes:
box1: eth0:5 192.121.234.213 netmask 255.255.255.240 broadcast
192.121.234.223
box2: lo:0 192.121.234.213 netmask 255.255.255.255
between box1 and box2 I have a OpenVPN tunnel (endpoints 10.1.0.1 and
10.1.0.2).

I want to forward all packages on box1 with destination 192.121.234.213 to
tun0 (10.1.0.1), so they pass through the tunnel and comes to box2. I also
want to forward all packages from tun0 (10.1.0.1) to eth0:5
(192.121.234.213). How do I do this with iptables?

Regards
Jonathan

Re: Route packets from an interface to another

[Edmundo Carmona]

IPTABLES? I think it's a routing problem, not a firewall one.

ip route add 192.121.234.213 via 10.1.0.2
I think that would do the first part of your problem.

But why do you have an IP address (not 127/8) set on a loopback interface? 

On 9/9/05, Jonathan <phonic@antisocial.nu> wrote:
> Hello,
> I have the following interface configuration on two boxes:
> box1: eth0:5 192.121.234.213 netmask 255.255.255.240 broadcast
> 192.121.234.223
> box2: lo:0 192.121.234.213 netmask 255.255.255.255
> between box1 and box2 I have a OpenVPN tunnel (endpoints 10.1.0.1 and
> 10.1.0.2).
> 
> I want to forward all packages on box1 with destination 192.121.234.213 to
> tun0 (10.1.0.1), so they pass through the tunnel and comes to box2. I also
> want to forward all packages from tun0 (10.1.0.1) to eth0:5
> (192.121.234.213). How do I do this with iptables?
> 
> Regards
> Jonathan
> 
> 
>

Re: Route packets from an interface to another

[Jonathan]

I have already set up routes exactly like that one. :-)

The purpose is that I want to have a static IP on my home box. I have a
/28 addressed on a box so I thought I could tunnel one of these addresses
to my box home.

And the problem; when I ping/ssh/whatever 192.121.234.213 from the /28-box
(box1), the traffic goes through 10.1.0.1 to 10.1.0.2 and reaches my home
box. But when I ping/ssh/whatever from outside the traffic goes to box1.
That's why I think NATing the connections will solve the problem. But
maybe I'm wrong?

> IPTABLES? I think it's a routing problem, not a firewall one.
>
> ip route add 192.121.234.213 via 10.1.0.2
> I think that would do the first part of your problem.
>
> But why do you have an IP address (not 127/8) set on a loopback interface?
>
> On 9/9/05, Jonathan <phonic@antisocial.nu> wrote:
>> Hello,
>> I have the following interface configuration on two boxes:
>> box1: eth0:5 192.121.234.213 netmask 255.255.255.240 broadcast
>> 192.121.234.223
>> box2: lo:0 192.121.234.213 netmask 255.255.255.255
>> between box1 and box2 I have a OpenVPN tunnel (endpoints 10.1.0.1 and
>> 10.1.0.2).
>>
>> I want to forward all packages on box1 with destination 192.121.234.213
>> to
>> tun0 (10.1.0.1), so they pass through the tunnel and comes to box2. I
>> also
>> want to forward all packages from tun0 (10.1.0.1) to eth0:5
>> (192.121.234.213). How do I do this with iptables?
>>
>> Regards
>> Jonathan
>>
>>
>>
>
>

Re: Route packets from an interface to another

[Edmundo Carmona]

Well.. routing in this case is not single point problem.... but both
points have to route correctly to make it "happen". You sure the other
machine is routing through the VPN tunnel when replying?

On 9/9/05, Jonathan <phonic@antisocial.nu> wrote:
> I have already set up routes exactly like that one. :-)
>
> The purpose is that I want to have a static IP on my home box. I have a
> /28 addressed on a box so I thought I could tunnel one of these addresses
> to my box home.
>
> And the problem; when I ping/ssh/whatever 192.121.234.213 from the /28-box
> (box1), the traffic goes through 10.1.0.1 to 10.1.0.2 and reaches my home
> box. But when I ping/ssh/whatever from outside the traffic goes to box1.
> That's why I think NATing the connections will solve the problem. But
> maybe I'm wrong?
>
> > IPTABLES? I think it's a routing problem, not a firewall one.
> >
> > ip route add 192.121.234.213 via 10.1.0.2
> > I think that would do the first part of your problem.
> >
> > But why do you have an IP address (not 127/8) set on a loopback interface?
> >
> > On 9/9/05, Jonathan <phonic@antisocial.nu> wrote:
> >> Hello,
> >> I have the following interface configuration on two boxes:
> >> box1: eth0:5 192.121.234.213 netmask 255.255.255.240 broadcast
> >> 192.121.234.223
> >> box2: lo:0 192.121.234.213 netmask 255.255.255.255
> >> between box1 and box2 I have a OpenVPN tunnel (endpoints 10.1.0.1 and
> >> 10.1.0.2).
> >>
> >> I want to forward all packages on box1 with destination 192.121.234.213
> >> to
> >> tun0 (10.1.0.1), so theWy pass through the tunnel and comes to box2. I
> >> also
> >> want to forward all packages from tun0 (10.1.0.1) to eth0:5
> >> (192.121.234.213). How do I do this with iptables?
> >>
> >> Regards
> >> Jonathan
> >>
> >>
> >>
> >
> >
>
>
>
>

Re: Route packets from an interface to another

[Edmundo Carmona]

Oh well.. that's not a good reason. ;)

What is the output of:

ip route show default

on both boxes??

I'll review it at home later... I'm leaving the office.

On 9/9/05, Jonathan <phonic@antisocial.nu> wrote:
> I think so. On box1 I type these commands:
> # ifconfig eth0:5 192.121.234.213 netmask 255.255.255.240 broadcast
> 192.121.234.223
> # ip route add 192.121.234.213 via 10.1.0.2 (10.1.0.2 is the tunnel's
> endpoint on box2)
> 
> on box1:
> # ifconfig lo:0 192.121.234.213 netmask 255.255.255.255
> # ip rule add from 192.121.234.213 lookup 10
> # ip route add default via 10.1.0.1 table 10
> 
> and when I ssh 192.121.234.213 from box1, I come to box2.
> 
> I have also noticed that 192.121.234.213 exists in the kernel routing
> table on box1, so I deleted it and when I then ssh 192.121.234.213 from
> the outside I get the error "no route to host".
> 
> So the routing seems to be correct, right?
> And why I set up the tunneled address on lo is because a guy told me to do
> that. ;-)
> 
> > Well.. routing in this case is not single point problem.... but both
> > points have to route correctly to make it "happen". You sure the other
> > machine is routing through the VPN tunnel when replying?
> >
> > On 9/9/05, Jonathan <phonic@antisocial.nu> wrote:
> >> I have already set up routes exactly like that one. :-)
> >>
> >> The purpose is that I want to have a static IP on my home box. I have a
> >> /28 addressed on a box so I thought I could tunnel one of these
> >> addresses
> >> to my box home.
> >>
> >> And the problem; when I ping/ssh/whatever 192.121.234.213 from the
> >> /28-box
> >> (box1), the traffic goes through 10.1.0.1 to 10.1.0.2 and reaches my
> >> home
> >> box. But when I ping/ssh/whatever from outside the traffic goes to box1.
> >> That's why I think NATing the connections will solve the problem. But
> >> maybe I'm wrong?
> >>
> >> > IPTABLES? I think it's a routing problem, not a firewall one.
> >> >
> >> > ip route add 192.121.234.213 via 10.1.0.2
> >> > I think that would do the first part of your problem.
> >> >
> >> > But why do you have an IP address (not 127/8) set on a loopback
> >> interface?
> >> >
> >> > On 9/9/05, Jonathan <phonic@antisocial.nu> wrote:
> >> >> Hello,
> >> >> I have the following interface configuration on two boxes:
> >> >> box1: eth0:5 192.121.234.213 netmask 255.255.255.240 broadcast
> >> >> 192.121.234.223
> >> >> box2: lo:0 192.121.234.213 netmask 255.255.255.255
> >> >> between box1 and box2 I have a OpenVPN tunnel (endpoints 10.1.0.1 and
> >> >> 10.1.0.2).
> >> >>
> >> >> I want to forward all packages on box1 with destination
> >> 192.121.234.213
> >> >> to
> >> >> tun0 (10.1.0.1), so theWy pass through the tunnel and comes to box2.
> >> I
> >> >> also
> >> >> want to forward all packages from tun0 (10.1.0.1) to eth0:5
> >> >> (192.121.234.213). How do I do this with iptables?
> >> >>
> >> >> Regards
> >> >> Jonathan
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >>
> >
> 
> 
>

Re: Route packets from an interface to another

[Jonathan]

I think so. On box1 I type these commands:
# ifconfig eth0:5 192.121.234.213 netmask 255.255.255.240 broadcast
192.121.234.223
# ip route add 192.121.234.213 via 10.1.0.2 (10.1.0.2 is the tunnel's
endpoint on box2)

on box1:
# ifconfig lo:0 192.121.234.213 netmask 255.255.255.255
# ip rule add from 192.121.234.213 lookup 10
# ip route add default via 10.1.0.1 table 10

and when I ssh 192.121.234.213 from box1, I come to box2.

I have also noticed that 192.121.234.213 exists in the kernel routing
table on box1, so I deleted it and when I then ssh 192.121.234.213 from
the outside I get the error "no route to host".

So the routing seems to be correct, right?
And why I set up the tunneled address on lo is because a guy told me to do
that. ;-)

> Well.. routing in this case is not single point problem.... but both
points have to route correctly to make it "happen". You sure the other
machine is routing through the VPN tunnel when replying?
>
> On 9/9/05, Jonathan <phonic@antisocial.nu> wrote:
>> I have already set up routes exactly like that one. :-)
>>
>> The purpose is that I want to have a static IP on my home box. I have a
/28 addressed on a box so I thought I could tunnel one of these
addresses
>> to my box home.
>>
>> And the problem; when I ping/ssh/whatever 192.121.234.213 from the /28-box
>> (box1), the traffic goes through 10.1.0.1 to 10.1.0.2 and reaches my home
>> box. But when I ping/ssh/whatever from outside the traffic goes to
box1. That's why I think NATing the connections will solve the problem.
But maybe I'm wrong?
>>
>> > IPTABLES? I think it's a routing problem, not a firewall one.
>> >
>> > ip route add 192.121.234.213 via 10.1.0.2
>> > I think that would do the first part of your problem.
>> >
>> > But why do you have an IP address (not 127/8) set on a loopback
>> interface?
>> >
>> > On 9/9/05, Jonathan <phonic@antisocial.nu> wrote:
>> >> Hello,
>> >> I have the following interface configuration on two boxes:
>> >> box1: eth0:5 192.121.234.213 netmask 255.255.255.240 broadcast
192.121.234.223
>> >> box2: lo:0 192.121.234.213 netmask 255.255.255.255
>> >> between box1 and box2 I have a OpenVPN tunnel (endpoints 10.1.0.1
and 10.1.0.2).
>> >>
>> >> I want to forward all packages on box1 with destination
>> 192.121.234.213
>> >> to
>> >> tun0 (10.1.0.1), so theWy pass through the tunnel and comes to box2.
>> I
>> >> also
>> >> want to forward all packages from tun0 (10.1.0.1) to eth0:5
>> >> (192.121.234.213). How do I do this with iptables?
>> >>
>> >> Regards
>> >> Jonathan
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>>
>

Re: Route packets from an interface to another

[/dev/rob0]

On Friday 2005-September-09 14:51, Jonathan wrote:
> I think so. On box1 I type these commands:

You think so, what? Is there some way I should be able to tell what 
you're on about? Please, this top-posting makes it very difficult; show 
some consideration for your readers.

> >> > On 9/9/05, Jonathan <phonic@antisocial.nu> wrote:
> >> >> I have the following interface configuration on two boxes:
> >> >> box1: eth0:5 192.121.234.213 netmask 255.255.255.240 broadcast
> 192.121.234.223
>
> >> >> box2: lo:0 192.121.234.213 netmask 255.255.255.255

lo:0 ?? Don't do this. Why are you trying to bind another IP to lo?

> >> >> between box1 and box2 I have a OpenVPN tunnel (endpoints
> >> >> 10.1.0.1 and 10.1.0.2).

Why these IP's? You could simplify by using the remote static IP as the 
IP for your home endpoint. IINM you wouldn't need NAT at all.

Remote eth0: 192.121.234.212 netmask 255.255.255.240
Remote tun0: 192.121.234.212 netmask 255.255.255.240
Home tun0 192.121.234.213 netmask 255.255.255.240

When something comes in on eth0 with a destination IP of 
192.121.234.213, your kernel knows it needs to go out tun0. If routing 
is enabled and nothing blocking it in table filter chain FORWARD, out 
it goes.

What you are talking about is indeed possible. I did it myself before 
figuring out the better way of doing it. :) You need to do both SNAT 
and DNAT.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Route packets from an interface to another

[Jonathan]

> On Friday 2005-September-09 14:51, Jonathan wrote:
>> I think so. On box1 I type these commands:
>
> You think so, what? Is there some way I should be able to tell what
> you're on about? Please, this top-posting makes it very difficult; show
> some consideration for your readers.
sorry. :-)
>
>> >> > On 9/9/05, Jonathan <phonic@antisocial.nu> wrote:
>> >> >> I have the following interface configuration on two boxes:
>> >> >> box1: eth0:5 192.121.234.213 netmask 255.255.255.240 broadcast
>> 192.121.234.223
>>
>> >> >> box2: lo:0 192.121.234.213 netmask 255.255.255.255
>
> lo:0 ?? Don't do this. Why are you trying to bind another IP to lo?
a guy I talked to told me to do it, I have no other explaination.
>
>> >> >> between box1 and box2 I have a OpenVPN tunnel (endpoints
>> >> >> 10.1.0.1 and 10.1.0.2).
>
> Why these IP's? You could simplify by using the remote static IP as the
> IP for your home endpoint. IINM you wouldn't need NAT at all.
>
> Remote eth0: 192.121.234.212 netmask 255.255.255.240
> Remote tun0: 192.121.234.212 netmask 255.255.255.240
> Home tun0 192.121.234.213 netmask 255.255.255.240
>
> When something comes in on eth0 with a destination IP of
> 192.121.234.213, your kernel knows it needs to go out tun0. If routing
> is enabled and nothing blocking it in table filter chain FORWARD, out
> it goes.
>
> What you are talking about is indeed possible. I did it myself before
> figuring out the better way of doing it. :) You need to do both SNAT
> and DNAT.
Yeah, your solution was much better than mine. :-p
If I understand you right, the only thing I have to do is to edit my
openvpn-config and restart the tunnel? No edit in routing tables? And I
have to set up 192.121.234.213 as an alias of eth0 at the remote box,
right?


I also found out this when I played with my solution. Dunno if it's
interesting...
I'm trying to establish an SSH session from a machine on a totally
different network.
# ssh 192.121.234.213
Read from socket failed: Connection reset by peer
# ssh 192.121.234.213
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
bla, bla, bla, bla. And the RSA key fingerprint belongs to box2. Then I
deleted the key from known_hosts and ssh'd again
# ssh 192.121.234.213
and I could log into box2.
but the connection freezed a second after the login, so I ssh'd again.
# ssh 192.121.234.213
ssh: connect to host 192.121.234.213 port 22: No route to host

192.121.234.213 was NOT in the kernel routing table at this time.
so I added it, flushed cache and deleted it again, and suddenly I could
log in and establish an IRC session. But then I tried to FTP to my home
box via 192.121.234.213 -- and everything freezed and I got the error
message "no route to host". Then I repeated the same procedure, but I
ftp'd the box first this time, and then ssh'd and established an IRC
session. Everything worked. But when I tried to reach the box via HTTP the
connection freezed.

Re: Route packets from an interface to another

[/dev/rob0]

On Friday 2005-September-09 16:18, Jonathan wrote:
> >> >> >> box2: lo:0 192.121.234.213 netmask 255.255.255.255
> >
> > lo:0 ?? Don't do this. Why are you trying to bind another IP to lo?
>
> a guy I talked to told me to do it, I have no other explaination.

It's simple to see why this is wrong. It's called "loopback", right? The 
packets loop back. You're wanting to route them outside. With enough 
NAT duct-tape and bubble-gum it could be made to work, but it's ugly.

> >> >> >> between box1 and box2 I have a OpenVPN tunnel (endpoints
> >> >> >> 10.1.0.1 and 10.1.0.2).
> >
> > Why these IP's? You could simplify by using the remote static IP as
> > the IP for your home endpoint. IINM you wouldn't need NAT at all.
> >
> > Remote eth0: 192.121.234.212 netmask 255.255.255.240
> > Remote tun0: 192.121.234.212 netmask 255.255.255.240
> > Home tun0 192.121.234.213 netmask 255.255.255.240
> >
> > When something comes in on eth0 with a destination IP of
> > 192.121.234.213, your kernel knows it needs to go out tun0. If
> > routing is enabled and nothing blocking it in table filter chain
> > FORWARD, out it goes.
> >
> > What you are talking about is indeed possible. I did it myself
> > before figuring out the better way of doing it. :) You need to do
> > both SNAT and DNAT.
>
> Yeah, your solution was much better than mine. :-p
> If I understand you right, the only thing I have to do is to edit my
> openvpn-config and restart the tunnel? No edit in routing tables? And

Yes.[1]

> I have to set up 192.121.234.213 as an alias of eth0 at the remote
> box, right?

Actually I think not. As long as the upstream router knows to send 
192.121.234.213 through you, and you have a route to 192.121.234.213, I 
think that's enough. Try it and see? I have a machine where I'll try it 
too.

[later: I tried it]

The problem, I believe, is the routing on the return. Packets get in, 
but replies are trying to go out through the default gateway.

The answer is indeed, either NAT or MARK/--set-mark/fwmark (iproute2). 
I'll mess around a bit more and let you know what I find. You are, of 
course, welcome to do the same. :)

[even later: success]

Sorry to take away your chance to shine, but I have solved this. :) It 
was easier than I thought.

Home machine: LAN address 192.168.6.6/24 (no direct external interface)
Remote machine: x.y.z.112/29

Home openvpn config:
remote x.y.z.112
ifconfig x.y.z.116 192.168.6.248
ifconfig-nowarn

Remote openvpn config:
remote my.dynamic.dnsname
ifconfig 192.168.6.248 x.y.z.116

Started both ends of the tunnel. At home:
# echo 64 tunnel >> /etc/iproute2/rt_tables
# ip rule add from x.y.z.116 table tunnel
# ip route add default via 192.168.6.248 table tunnel
# ip route flush cache
(These should go in an openvpn --up script.)

As it happens, no explicit iptables rules were needed! YMMV depending 
upon the rules you have, of course. I do the firewalling on the remote, 
so only allowed services and replies to my own connections go through 
the tunnel. I had to make sure the filter/FORWARD chain on the remote 
would pass the packets I needed. Here at home, filter/INPUT accepts 
anything from that interface.

Thanks for the idea, and for the learning experience! I left in the 
process, including the incorrect hypotheses. Please note that the 
affirmative reply above about NOT needing to edit routing tables was 
not correct.

[large snip]
> established an IRC session. Everything worked. But when I tried to
> reach the box via HTTP the connection freezed.

These things, it's hard to say what they might be. Sounds like a 
possible physical layer problem. It doesn't sound likely to be a 
netfilter issue.



[1] Believed at the time, later proven untrue.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Route packets from an interface to another

[/dev/rob0]

On Friday 2005-September-09 23:45, I wrote:

Most of the story, but an important part was missing. Apologies to 
anyone who is seeing this on both lists.

> Home machine: LAN address 192.168.6.6/24 (no direct external
> interface) Remote machine: x.y.z.112/29
>
> Home openvpn config:
> remote x.y.z.112
> ifconfig x.y.z.116 192.168.6.248
> ifconfig-nowarn
>
> Remote openvpn config:
> remote my.dynamic.dnsname
> ifconfig 192.168.6.248 x.y.z.116
>
> Started both ends of the tunnel. At home:
> # echo 64 tunnel >> /etc/iproute2/rt_tables
> # ip rule add from x.y.z.116 table tunnel
> # ip route add default via 192.168.6.248 table tunnel
> # ip route flush cache
> (These should go in an openvpn --up script.)

Also, at the remote:
# echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
# echo 1 > /proc/sys/net/ipv4/ip_forward
(These might be wanted in an --up script at the other endpoint.)

The first command tells the eth0 interface (substitute the name of 
yours) to listen for proxy ARP: hosts other than itself, but for whom 
it has an explicit route. http://en.wikipedia.org/wiki/Proxy_ARP 
explains better than I can.

Earlier, by accident, I had bound the wrong IP's at each endpoint, so 
the system arp(8) cache was still answering for x.y.z.116. In time the 
cache timed out, and the tunnel stopped working.

The second command is not needed if you were already using the machine 
as a router, which I was, but it occurred to me that you and others 
might not be doing that.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Route packets from an interface to another

[Jonathan]

Yeah, it works. :-)
Thank you for your interest in my problem, and your ambition to help me.
I've never solved it myself. ;-)

> On Friday 2005-September-09 23:45, I wrote:
>
> Most of the story, but an important part was missing. Apologies to
> anyone who is seeing this on both lists.
>
>> Home machine: LAN address 192.168.6.6/24 (no direct external
>> interface) Remote machine: x.y.z.112/29
>>
>> Home openvpn config:
>> remote x.y.z.112
>> ifconfig x.y.z.116 192.168.6.248
>> ifconfig-nowarn
>>
>> Remote openvpn config:
>> remote my.dynamic.dnsname
>> ifconfig 192.168.6.248 x.y.z.116
>>
>> Started both ends of the tunnel. At home:
>> # echo 64 tunnel >> /etc/iproute2/rt_tables
>> # ip rule add from x.y.z.116 table tunnel
>> # ip route add default via 192.168.6.248 table tunnel
>> # ip route flush cache
>> (These should go in an openvpn --up script.)
>
> Also, at the remote:
> # echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
> # echo 1 > /proc/sys/net/ipv4/ip_forward
> (These might be wanted in an --up script at the other endpoint.)
>
> The first command tells the eth0 interface (substitute the name of
> yours) to listen for proxy ARP: hosts other than itself, but for whom
> it has an explicit route. http://en.wikipedia.org/wiki/Proxy_ARP
> explains better than I can.
>
> Earlier, by accident, I had bound the wrong IP's at each endpoint, so
> the system arp(8) cache was still answering for x.y.z.116. In time the
> cache timed out, and the tunnel stopped working.
>
> The second command is not needed if you were already using the machine
> as a router, which I was, but it occurred to me that you and others
> might not be doing that.
> --
>     mail to this address is discarded unless "/dev/rob0"
>     or "not-spam" is in Subject: header
>
>

Re: Route packets from an interface to another

[/dev/rob0]

On Monday 2005-September-12 02:56, Jonathan wrote:
> Yeah, it works. :-)
> Thank you for your interest in my problem, and your ambition to help
> me. I've never solved it myself. ;-)

My real ambition is always my own education, and I learned some handy 
tricks from this. :) So I'm happy with the result, even though I don't 
really need the static IP at home.

For the record and sake of completeness there's a minor correction:

> >> Started both ends of the tunnel. At home:
> >> # echo 64 tunnel >> /etc/iproute2/rt_tables
> >> # ip rule add from x.y.z.116 table tunnel
> >> # ip route add default via 192.168.6.248 table tunnel
> >> # ip route flush cache
> >> (These should go in an openvpn --up script.)

The first command obviously would NOT belong in a script. You only run 
that once. The latter commands might not always need to be run, 
depending on the state of the system routing tables at the time. You 
might also want a --down script to clean up the routing, or commands 
flushing the tunnel rule and table preceding those in the --up script.

Someone on a truly dynamic IP would want a --float option, and related 
options to enable reestablishment of the tunnel after the IP changes.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Route packets from an interface to another

[Rudi Starcevic]

Hi,

I do something like this with the script below.

Please let me know if you see a better way to do this
than I am using below.

Thanks.
Kind regards,
Rudi.


#!/bin/sh

echo "Network Setup Start"

echo "Flushing NICs"
ip addr flush eth0
ip addr flush eth1

ip link set eth0 down
ip link set eth1 down

ip link set eth0 up
ip link set eth1 up

echo "Flushing NetFilter"
iptables -F
iptables -t nat -F

echo "Routing Tables:"
cat /etc/iproute2/rt_tables

echo "Setup NIC 0"
ip addr add 192.168.2.7/24 dev eth0 brd +

echo "Setup NIC 1"
ip addr add 192.168.3.7/24 dev eth1 brd +

ip addr list
ip route list

echo "Setup Default Route [ inet table ]"
ip route add default via 192.168.2.1 proto static table inet

echo "Setup LAN Route [ implan table ]"
ip route add 192.168.3/24 via 192.168.3.7 proto static table implan

ip route list

echo "Setup LAN ip rule"
ip rule add to 192.168.3/24 prio 16000 table implan

echo "Setup Internet ip rule"
ip rule add to 0/0 prio 17000 table inet

echo "Enable Kernel Forwarding"
echo "1" > /proc/sys/net/ipv4/ip_forward

echo "Enable NetFilter Forwarding"
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

echo "Flushing ip route cache"
ip route flush cache

#iptables -vL
#iptables -t nat -vL

exit 0

Re: Route packets from an interface to another

[/dev/rob0]

On Monday 2005-September-12 08:36[1], Rudi Starcevic is planning to 
write:
> I do something like this with the script below.

You're using NAT. I don't see the similarity. What the OP was talking 
about doing, and what I did, was to implement a remote IP address 
(routable, not RFC 1918) through an openvpn connection using proxy ARP 
and multiple routing tables. You're using multiple routing tables, but 
that's all the similarity I can see.

Unfortunately, the matter as previously posted really came down to be 
off-topic for this list. I'm not using any special iptables rules, be 
they mangle, nat nor filter tables. This is on topic at the OpenVPN 
users list (where I did post it) and perhaps also at LARTC.

> Please let me know if you see a better way to do this
> than I am using below.

I don't really know what you're doing!

> echo "Flushing NICs"
> ip addr flush eth0
> ip addr flush eth1
>
> ip link set eth0 down
> ip link set eth1 down
>
> ip link set eth0 up
> ip link set eth1 up
>
> echo "Flushing NetFilter"
> iptables -F
> iptables -t nat -F
>
> echo "Routing Tables:"
> cat /etc/iproute2/rt_tables

You have added "inet" and "implan" tables, but we don't know what they 
are nor what they are used for.

> echo "Setup NIC 0"
> ip addr add 192.168.2.7/24 dev eth0 brd +
>
> echo "Setup NIC 1"
> ip addr add 192.168.3.7/24 dev eth1 brd +

> echo "Setup Default Route [ inet table ]"
> ip route add default via 192.168.2.1 proto static table inet
>
> echo "Setup LAN Route [ implan table ]"
> ip route add 192.168.3/24 via 192.168.3.7 proto static table implan

Clues here. Looks like eth0 goes to a NAT router on 192.168.2.1, and 
eth1 goes to a LAN (which is double-SNAT'ed out eth0.)

> echo "Setup LAN ip rule"
> ip rule add to 192.168.3/24 prio 16000 table implan
>
> echo "Setup Internet ip rule"
> ip rule add to 0/0 prio 17000 table inet
>
> echo "Enable Kernel Forwarding"
> echo "1" > /proc/sys/net/ipv4/ip_forward
>
> echo "Enable NetFilter Forwarding"
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

MASQUERADE is a form of source NAT, not forwarding, strictly speaking. 
It's useful to understand the difference. Furthermore it's not 
appropriate in this case, where (I presume) you have a static IP on 
eth0. (If not, you probably should.)

And the whole purpose is unclear. If you've got a NAT router on eth0, 
why not connect your LAN to that? Why the extra hop?

> echo "Flushing ip route cache"
> ip route flush cache



[1] "Date: Mon, 12 Sep 2005 06:36:02 -0700" is still in the future at 
this writing.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Route packets from an interface to another

[Rudi Starcevic]

Hi,

> I don't really know what you're doing!

Really ... there's only a few lines, I kept them to a minimum
so one could simply read them and one can see what happening.

> You have added "inet" and "implan" tables, but we don't know what they
> are nor what they are used for.

Ummm ... 'inet' means internet and 'implan' mean Local Area Network.

I though this was intuitive and explains itself, there is only two after
all.

> MASQUERADE is a form of source NAT, not forwarding, strictly speaking. 
> It's useful to understand the difference. Furthermore it's not 
> appropriate in this case, where (I presume) you have a static IP on 
> eth0. (If not, you probably should.)
> 
> And the whole purpose is unclear. If you've got a NAT router on eth0, 
> why not connect your LAN to that? 

Well first up I want to learn how to route from one interface to
another. I don't know if this is the best way, I'm reading up by myself
and making an effort to try figure it out.

>> Why the extra hop?

I want to split up my machines and networks, enable bandwith controls,
control access to resources add securtiy etc etc etc .....


Regards,
Rudi.

Re: Route packets from an interface to another

[Rudi Starcevic]

Hi,

> and perhaps also at LARTC.

Yes. The LARTC list has been down over a month.
I've been waiting to post to LARTC about this subject.

I did see someone else start this off-topic thread and get
several replies so I've added my 2 cents in the hope I'll
learn more about routing between interfaces.

Regards,
Rudi.

Route packets from an interface to another

[vinod K D]

First of all, I'll explain my network setup.
 
 My gateway has two network interfaces: eth0 & eth1. 
 
 eth0 (192.168.1.1) is connected to public network and
eth1(10.0.1.1) is connected to LAN.
 
 MyServer, which is in the LAN, has ip 10.0.1.2.
 
 I created a virtual interface eth0:0 (192.168.1.2) in
the gateway.
 Using ipvsadm, I can route the packets, destined for
this IP address and a port,  to myServer.
 
 And in myServer, I enabled ip_forwarding and assigned
192.168.1.2 for the loopback interface. 
 So my server application receives and serves the
packets properly. 
 
 The problem is in the return path. (Remember the
packets have source addres 192.168.1.2). While they
reach the gateway, the packets are being dropped. 
 
 (I think, the reason is nothing but the address
192.168.1.2 is assigned to the gateway. Hence router
assumes the packets are traversing though a loop.)
 
 I can't use masquerading, because I need to get the
source & destination IPs of the packets.
 
 Can anyone suggest a way to redirect packets from an
interface to another (ie, eth1 to eth0) without making
any change in the packet header.
 
 PS: The latest versions of netfilter doen't have
inbuilt ipt_ROUTE module. Else my life would be cool.
 
 Thanks,
 Vinod


       
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's 
Comedy with an Edge to see what's on, when. 
http://tv.yahoo.com/collections/222

Re: Route packets from an interface to another

[Grant Taylor]

On 09/10/07 07:18, vinod K D wrote:
> My gateway has two network interfaces: eth0 & eth1.
> 
> eth0 (192.168.1.1) is connected to public network and eth1 (10.0.1.1) 
> is connected to LAN.
> 
> MyServer, which is in the LAN, has ip 10.0.1.2.

Ok, reasonable enough.

> I created a virtual interface eth0:0 (192.168.1.2) in the gateway. 
> Using ipvsadm, I can route the packets, destined for this IP address 
> and a port,  to myServer.
> 
> And in myServer, I enabled ip_forwarding and assigned 192.168.1.2 for 
> the loopback interface.  So my server application receives and serves 
> the packets properly.

I'm surprised that having the 192.168.1.2 address on the loopback 
interface is working as expected at all as the kernel will usually 
protect the loopback interface from any thing not local to the system.

> The problem is in the return path. (Remember the packets have source 
> addres 192.168.1.2). While they reach the gateway, the packets are 
> being dropped.

*nod*  You will indeed have some reverse path issues to work out.

> (I think, the reason is nothing but the address 192.168.1.2 is 
> assigned to the gateway. Hence router assumes the packets are 
> traversing though a loop.)

*nod*

> I can't use masquerading, because I need to get the source & 
> destination IPs of the packets.

Ok...

I have to ask, why does your server have a private class C address on 
its external interface?  Either you are doing something weird and your 
external is not external to the internet or you are already in a 
situation where the packets have been modified as you are trying to 
avoid.  I'm just saying / opening the door for an answer.

> Can anyone suggest a way to redirect packets from an interface to 
> another (ie, eth1 to eth0) without making any change in the packet 
> header.

Why redirect the packets at all.  Why not let the packets come in 
directly to the router?

I'd suggest that you turn your router in to a bridging router.  I.e. 
bridge traffic to / from 192.168.1.2 through eth0 and eth1 while routing 
192.168.1.1 traffic for your LAN?  This way your server would have 
192.168.1.2 bound to its NIC and be able to reply directly to the world 
with out any problem at all.  If you are worried about not having a 
firewall, you can easily do either EBTables (layer 2) or IPTables (layer 
3) on the bridged (layer 2) traffic so your system will still be protected.

Do some light reading of section 7 of the following page: 
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html#section7  I think 
this will help depict what I'm talking about.

> PS: The latest versions of netfilter doen't have inbuilt ipt_ROUTE 
> module. Else my life would be cool.




Grant. . . .