# Strange routing question...

## depontius

I would like to start a tun device and simply route it through my eth0 or wifi0 device, and have that be my default route.

Slightly longer.  I use my laptop as a workstation, so it generally has a whole pile of stuff running on it, and those things tend to keep a pile of open network connections.  I would like to suspend the laptop, take it out of the dock and to a conference room, open it and establish a wifi connection, and get back to work.  With a "walk time" of 5 minutes or so, most connections could survive or at least cope.  (retry)  But they clearly wouldn't like seeing the networking stack change under them like that, and in fact I think every connection would get irreparably severed by the network change.  But if the default route were through the tun device, and it were routed through my real network device, then I think things just might work.

Can this be done?

How?

An alternative would be to use a VM, doing all of my real work in the VM and using the real machine only as a minimal host, and using a routed connection to get the network into a VM.  But VMs are pretty heavy, and I'd like to do this at a lighter weight.

An additional twist...  Suspend the machine, take it home, connect to my home LAN. open the company VPN, and now route my extra tun device through the VPN.  As far as my applications would know, the machine is on the company network and never left.  There's an additional complication in that our VPN uses the tun0 device.  It *should* be able to see that tun0 is already in use and adjust to use tun1 for the tunnel, but we all know how "shoulds" tend to work.

----------

## nativemad

Hi,

i don't know if that can be so easily done and this is just pure theory... so don't blame on me if it doesn't work!   :Wink: 

build a bridge with every interface that faces the external net, plus an internal addidional tun device. If you use VPN, then you should remove the external interfaces and only use tuns...

```

tunctl -t tun1

brctl addbr br0

brctl addif br0 eth0 eth1 tun1

ifconfig br0 up
```

now you will use another ip within the net of the real interfaces on tun1

....better use a static ip here, as when no real interface is up, the dhcp client could fall to a 169 address...

Be aware that you have to mostly specify the interface to use like `ping -I tun1` ....

HTH, cheers

----------

## Hu

OP: can you guarantee that you have the same IP address throughout?  Most applications do not care much about changes to the routing table, as long as they can continue to use a socket bound to the same IP address they had before the sleep event.  Switching from wired to wireless has a good chance of giving you a different IP address, since most sites will not have those users lumped together.

----------

## depontius

nativemad - I don't believe I can use bridging, because it's company LAN, though I guess that through the bridge you end up getting a second dhcp lease.  But that's still a problem, because as I would move the laptop from my desk to a conference room and from eth0 to wifi0 I'd also be moving subnets.  In this case, I'm specifically after a routed solution so that my "fictional default" interface would keep a constant IP.  (Which is what Hu is talking about.)

Though I will say that something looks odd to me, and I think it displays my lack of understanding.  I think of bridging as keeping both interfaces on the same subnet.  Yet usually when bridging I thought on used a tap device instead of a tun device.  I though tap was for bridging and tun for routing.

Hu - You've hit the point here.  I want the tun0 interface specifically so it can keep a constant IP.  You're also right in that moving around inside the site will change my real IP address, which is why I'm wishing to route to a "fictional default" IP on a tun interface.

----------

## nativemad

Oh, sorry! I have to admit that i haven't read up the exact difference between tun and tap until now!    :Embarassed: 

Of course you will need tap devices for a bridge! And my suggestion would only work on the same subnet! (but bridges are actually one or two osi layers deeper than tcp/ip with subnets). 

If also the subnet changes, you should use iproute 2 with a nat for the failover. But even with that it is probably also just a matter of tcp-timeouts and how fast you are moving! Furthermore, i don't know how well this will work with dhcp leases!? Maybe you would have to adjust the ruleset every time an ip changes on the interface itself.

```

[eth0]--|

        |

        |--iproute2-and-nat-for-tap0---[tap0 with a fix private ip]-your apps

        |

[eth1]--|

```

If you move too slow, you could gain even a bit more delay if you add another tap device and bridge it with tap0.

```

[eth0]--|

        |

        |--iproute2-and-nat-for-tap0---[tap0 with a fix private ip]----bridge-with-nat-to-tap0--------[tap1 with prvtip]--your-apps

        |

[eth1]--|
```

Bear in mind that this is highly experimental and i do not know how many innocent kitties will die if you actually try it!  :Rolling Eyes: 

Hu: In the first post here i just thought about the abrupt session close if the interface goes really down... A third ip that would just see both subnets would have been the easiest way i think. But please keep on intervening here, maybe you can save a little cat's live!   :Wink: 

----------

## boerKrelis

For TCP, I guess you might be able to solve the problem (resuming connections) on *your* side, however, what about the other side? How is the other side supposed to know that the packets now arriving from a different IP/src port somehow belong to the (now defunct) previous connection?

----------

## depontius

Oops - good point.  I guess for any chance, the connections have to originate from my side - then they have to fail.  When my side retries the connections, they go through, through the new real IP and real route.  But I still think that the constant fictional IP is necessary for the software on my side.

----------

## boerKrelis

I read somewhere that IPv6 has nice 'mobile roaming' support. This might suit your needs..... some day when your network and all its servers are IPv6 and the mobile roaming part is implemented ;-)

----------

## depontius

Well it's not my network, it's the company's.  Given that workstations just finished migrating to RedHat 5 last year, I'm not holding my breath for IPV6.  I've done a bit more looking, and at this point suspect that I need a local RFC1918 address, and masquerade that onto whatever real address my real interface gives me.

It's the details of how to do that that elude me.  From what more I've read of tun devices, they're all point-to-point tunnels, and I guess it's usually VPN code that connects the tunnel to something real.  It sounds like I want a trivial "non-encrypting null VPN, whatever that may mean.  I'd like to pick one off the shelf, but I don't believe there's one sitting there.

----------

## boerKrelis

 *depontius wrote:*   

> I've done a bit more looking, and at this point suspect that I need a local RFC1918 address, and masquerade that onto whatever real address my real interface gives me.

 

I think TCP connections (kinda stateful) will still break because your peer will not be able to match the packets coming from a new ip/srcport combo to the existing (but soon to be defunct) TCP connection. If your peer would send a packet down the connection it would get no ACK (you moved to a new IP, from the peer's POV) and would therefore destroy the connection, which will be noticed by the application layer.

It takes two to tango with TCP.

 *Quote:*   

> 
> 
> It's the details of how to do that that elude me.  From what more I've read of tun devices, they're all point-to-point tunnels, and I guess it's usually VPN code that connects the tunnel to something real.  It sounds like I want a trivial "non-encrypting null VPN, whatever that may mean.  I'd like to pick one off the shelf, but I don't believe there's one sitting there.

 

You might be able to succeed with net-misc/tinc . You'll need a partner-in-crime peer PC, also with tinc, which masquerades your connections. Tinc's tunnel is over UDP and is quite resilient to transient network failures; however, you'll need to find out if your tinc peer allows you to migrate to another IP.

----------

## depontius

 *boerKrelis wrote:*   

> I think TCP connections (kinda stateful) will still break because your peer will not be able to match the packets coming from a new ip/srcport combo to the existing (but soon to be defunct) TCP connection. If your peer would send a packet down the connection it would get no ACK (you moved to a new IP, from the peer's POV) and would therefore destroy the connection, which will be noticed by the application layer.
> 
> It takes two to tango with TCP.

 

But at this point it should look like a "temporary routing failure", which is one of those things tcp/ip was meant to be able to overcome.  The route fails because one of the steps along to path failed.  The system notes that and finds a new route.  The key is that all of this happens in the stack, and my application keeps its socket.  That the point that needed to be "routed around" was actually my own system should be a mere detail.

 *Quote:*   

> 
> 
> It's the details of how to do that that elude me.  From what more I've read of tun devices, they're all point-to-point tunnels, and I guess it's usually VPN code that connects the tunnel to something real.  It sounds like I want a trivial "non-encrypting null VPN, whatever that may mean.  I'd like to pick one off the shelf, but I don't believe there's one sitting there.

 

You might be able to succeed with net-misc/tinc . You'll need a partner-in-crime peer PC, also with tinc, which masquerades your connections. Tinc's tunnel is over UDP and is quite resilient to transient network failures; however, you'll need to find out if your tinc peer allows you to migrate to another IP.[/quote]

Aren't we then just building a VPN?  It seems to me that I should be able to grab the stuff from the tun device and simply route them to eth0/wlan0.  I see where "tunctl" is used for managing tun and tap devices, and others in this thread have referred to it, but there is no "tunctl" in portage.  Any idea what package provides it?

----------

## boerKrelis

 *depontius wrote:*   

> 
> 
> But at this point it should look like a "temporary routing failure"
> 
> 

 

I'm afraid it won't look like that from your peer's perspective. You changing routes lets you keep the same src ip / src port from the peer's POV. So yes, that would work. Except you're not just changing routes.

You want to change src ip / src port of your "connections"* (from the peer's perspective).

*but the new packets will never be part of the former connection, unless TCP is somehow extended to allow migrations.

Even if you let some third host do NAT for you, keeping a stable src ip, from the POV of the peer you'll change src ports as this third NATting host will assign the (new, since you changed IP from *his* perspective!) connections another src port.

 *depontius wrote:*   

> 
> 
> I see where "tunctl" is used for managing tun and tap devices, and others in this thread have referred to it, but there is no "tunctl" in portage.  Any idea what package provides it?

 

sys-apps/usermode-utilities .

----------

## AngelKnight

 *depontius wrote:*   

> I would like to start a tun device and simply route it through my eth0 or wifi0 device, and have that be my default route.

 

This assumes the device on the other end of the tun will automagically know how to reach your device via eth0 or wifi0 as the workstation's connectivity changes.  If one is not deliberately running dynamic routing (OSPF, BGP, RIP or something else) between the workstation and the tunnel's remote end's device, this is probably unlikely.

Setting the above aside, the basics for doing the right bits on the workstation side are probably:

```
/sbin/ip route replace $TUNNEL_PEER_IP via $TUNNEL_PEER_GATEWAY dev $APPROPRIATE_DEVICE

/sbin/ip route replace $TUNNEL_PEER_GATEWAY dev $APPROPRIATE_DEVICE

/sbin/ip route replace default via $TUNNEL_PEER_IP
```

Customizing the above to one's setup, as well as running the right scripts when one's workstation connects and disconnects from eth0, I leave as an exercise for the reader.

----------

## depontius

Putting together everything I've learned on this thread, I think I need a "null VPN" and an endpoint that will stay put.  The problem being, as other have said, that these connections I want to preserve need to have a stable IP/port# at both ends.  I've just been worrying here about the laptop side, but the concern is equally valid for the other end of the connection as well.  I do have a "stationary" machine which I could use as the other end of the connection.  I just need to rethink exactly what I'm trying to do.

It seems odd to me that this isn't some sort of FAQ - that people aren't more commonly trying to keep networked applications alive over a susped/resume with the attendant IP changes.

EDIT:

I think "openl2tp" may be able to do exactly what I want, given client and server machines.  It isn't in portage, but there is an ebuild avaiable on the bugzilla.

----------

