Multiple Interfaces, Same IP

Quicksearch

Syndicate This Blog

ATOM 1.0 feed

Comments

Wouter Verhelst about What's the Purpose Here?

Fri, 09.07.2010 17:45

I got one of those too, and go t interested. Turns out tha t they actually meant what the y wrote: they did send a [...]

vvill about What's the Purpose Here?

Thu, 08.07.2010 15:17

I doubt it's just being silly or funny or cute... I get my s hare of phishing emails of all sorts, and I'll bet it [...]

Andrew Latham about What's the Purpose Here?

Thu, 08.07.2010 14:41

They are attempting to "untrai n" any anti-spam system you ha ve. The goal is to poision th e words list. This is o [...]

Simon about Extensible Database Backends

Thu, 24.06.2010 23:53

Note that extensions are loade d in the connection subprocess , that is, an unstable module will not pull the entire [...]

Wil van lierop about Extensible Database Backends

Thu, 24.06.2010 19:54

A definite *yes*. or at least a clear way of making that dis tinction in marking them. A s with all popular scrip [...]

Friday, February 5. 2010

Multiple Interfaces, Same IP

Playing around a bit with ssh tunneling right now. When I create a kind of VPN concentrator with a few tun interfaces: is there any reason why I can't just assign the same IP on all these tun interfaces? A quick test shows this set up working nicely, with ifconfig tunX localip pointopoint remoteip (the localip part being the same) setting up the routes to chose the right tun device for all remote IP addresses, and ping worked just fine for me. Firewall rules will always have the remote IP and/or the interface name to decide when a packet applies.

Obviously setting up a listening socket at only one of these interfaces is not so trivial now since I can't just listen to the IP, but that's a restriction I'm happy with. Anything else I'm not thinking of right now?

Posted by Adrian von Bidder in Tech at 12:47 | Comments (5) | Trackbacks (0)

< IPv6 sucks. | Extensible Database Backends >

Comments

Display comments as (Linear | Threaded)

Having multiple interfaces with the same IP address was always the standard configuration of a terminal server with multiple PPP and SLIP links. The default configuration of Portslave always had a single IP address for the local end of all PPP/SLIP connections and there was no documentation on how to do otherwise. A few years ago when such things were common there didn't seem to be any problems doing it. Of course things may have changed since then.

#1 Russell Coker (Homepage) on 2010-02-05 13:20 (Reply)

That works nicely for me for *years* now.

#2 Joerg Jaspert on 2010-02-05 14:19 (Reply)

I think "setting up a listening socket at only one of these interfaces" is the historical reason why it's not commonly done. It also breaks SNMP, which uses the IP address as the primary key in the ipAddressTable. In general, the localip could also be an RFC1918 address if you wanted to conserve routeable addresses, but this might conflict with your peer's setup.

#3 GyrosGeier on 2010-02-05 14:24 (Reply)

Rather than some custom SSH-tunnel-based VPN, do yourself the favour and use OpenVPN instead. It supports tap interfaces, which means that you don't have to have any internal addresses, but it can manage tun interfaces too, either with a separate pool each, or out of one large common pool.

#4 martin f. krafft (Homepage) on 2010-02-05 20:58 (Reply)

Ask on debian-user mailing list. (i.e don't turn debian-planet into a support "mailing list").

#5 Franklin Piat on 2010-02-05 22:59 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	E-Mail addresses will not be displayed and will only be used for E-Mail notifications. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above:
	Remember Information? Subscribe to this entry
Submitted comments will be subject to moderation before being displayed.