Linux source selection

[pelican]

Hi all,

Got my tunnel up and running successfully, but I'm having a problem with the source address of outgoing packets.

I'm not providing any IPv6 service outside of the tunnel endpoint machine currently, so I've got my "real" address from the /64 on my loopback interface, and the tunnel endpoint on my tunnel interface:

hetun     Link encap:IPv6-in-IPv4 
          inet6 addr: 2001:470:1f03:f7c::2/64 Scope:Global
          inet6 addr: fe80::4c4a:9845/64 Scope:Link
          inet6 addr: fe80::4c4a:ec5b/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:1486 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2608 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:465364 (454.4 KiB)  TX bytes:306975 (299.7 KiB)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: 2001:470:1f01:4064:1::1/128 Scope:Global
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4215005 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4215005 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1526313891 (1.4 GiB)  TX bytes:1526313891 (1.4 GiB)

In this set-up, any packets leaving the machine are sent with a source address of 2001:470:1f03:f7c::2, which is not what I want.

So, I did some digging, and found the command:

ip addr change 2001:470:1f03:f7c::2/64 dev hetun preferred_lft 0

which takes the tunnel point-to-point link out of the address selection algorithm, and all my packets are sourced nicely.

However, a problem :(

This causes *all* packets to have a source of 2001:470:1f01:4064:1::1, even replies to ones sent directly to 2001:470:1f03:f7c::2.  So the HE ping6 test doesn't see the reply it's expecting, and eventually my tunnel times out.

Does anyone know how to make Linux behave such that any packets sent out are sourced from the loopback address, *unless* they're in reply to a packet sent to some other address (e.g. the tunnel address), in which case use the address they were sent to as the source?

Or to put it another way, I guess, all reply packets come from the address the original was sent to, all new packets come from the loopback.  (I don't know if that's easier to express as a ruleset somewhere).

Debian running 2.6.26, can get versions of other programs if needed.

Thanks in advance,
Tim.

[jimb]

Only thing I can think of off the top of my head is to employ ip6tables to try to match such traffic (perhaps by marking) and then NAT the source IP on egress.

But why do you care what the source IP of outgoing traffic is?  It's only "natural" for outgoing traffic from a host with multiple addresses to use the "nearest" as the source IP.  You should also be able to configure most programs to use the IP address or interface of your choosing, if this is really a big concern.

And of course, from the outside, the called interface replies to traffic:

{root@gts/pts/0}~# ping6 -c3 -n 2001:470:1f03:f7c::2
PING 2001:470:1f03:f7c::2(2001:470:1f03:f7c::2) 56 data bytes
64 bytes from 2001:470:1f03:f7c::2: icmp_seq=1 ttl=59 time=20.7 ms
64 bytes from 2001:470:1f03:f7c::2: icmp_seq=2 ttl=59 time=50.1 ms
64 bytes from 2001:470:1f03:f7c::2: icmp_seq=3 ttl=59 time=21.7 ms

--- 2001:470:1f03:f7c::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 20.709/30.875/50.167/13.648 ms

{root@gts/pts/0}~# ping6 -c 3 2001:470:1f01:4064:1::1
PING 2001:470:1f01:4064:1::1(2001:470:1f01:4064:1::1) 56 data bytes
64 bytes from 2001:470:1f01:4064:1::1: icmp_seq=1 ttl=59 time=22.1 ms
64 bytes from 2001:470:1f01:4064:1::1: icmp_seq=2 ttl=59 time=23.0 ms
64 bytes from 2001:470:1f01:4064:1::1: icmp_seq=3 ttl=59 time=21.6 ms

--- 2001:470:1f01:4064:1::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 21.650/22.284/23.041/0.587 ms

[snarked]

see "ip addrlabel", especially its "add prefix" subcommand.

PS:  Your routed /64 or /48 address belongs on a non-loopback interface other than your tunnel interface.

[jimb]

see "ip addrlabel", especially its "add prefix" subcommand.

PS:  Your routed /64 or /48 address belongs on a non-loopback interface other than your tunnel interface.

Ah interesting.  I thought I'd explored all the options of iproute2 but I missed that one somehow.

[pelican]

But why do you care what the source IP of outgoing traffic is?  It's only "natural" for outgoing traffic from a host with multiple addresses to use the "nearest" as the source IP.  You should also be able to configure most programs to use the IP address or interface of your choosing, if this is really a big concern.

Part ease of log-file reading (and cosmetic to an extent), part habit from my networking day-job.

On the former, it's just easier to follow what's going on in the logs elsewhere if connections are from my hostname, not some length auto-generated name from HE.

On the latter, I'm used to setting up everything on routers based on only ever communicating to and from the loopback address, on the assumption that the WAN links in use and their addresses can and will change.  I don't like to build ACLs, for example, based on WAN addressing.

And of course, from the outside, the called interface replies to traffic:

Ah, when I first set it up, it wasn't.  I was pinging the address from the routed /64 and getting replies from the tunnel endpoint, which is partly what kicked this off.  Thanks for independent confirmation that it doesn't do this now.

Cheers,
Tim.

[pelican]

see "ip addrlabel", especially its "add prefix" subcommand.

Thanks, I'll have another dig.

PS:  Your routed /64 or /48 address belongs on a non-loopback interface other than your tunnel interface.

Out of curiosity, is there something magic about loopback interfaces that causes this to break?

There's only one physical host in a co-lo at the end of this tunnel, any addresses beyond the first are going to be vhosts of some kind.  Binding the addresses to the loopback, rather than the LAN where they're never going to talk to anything and just run the risk of emitting spurious ND (or more worrying RA, if I manage to get the config wrong somewhere) seemed sensible to me.

Cheers,
Tim.

[jimb]

But why do you care what the source IP of outgoing traffic is?  It's only "natural" for outgoing traffic from a host with multiple addresses to use the "nearest" as the source IP.  You should also be able to configure most programs to use the IP address or interface of your choosing, if this is really a big concern.

Part ease of log-file reading (and cosmetic to an extent), part habit from my networking day-job.

On the former, it's just easier to follow what's going on in the logs elsewhere if connections are from my hostname, not some length auto-generated name from HE.

On the latter, I'm used to setting up everything on routers based on only ever communicating to and from the loopback address, on the assumption that the WAN links in use and their addresses can and will change.  I don't like to build ACLs, for example, based on WAN addressing.

Ah OK.  Yeah I'm familiar with the practice of using loopbacks instead of interface addresses for various things too.  I've wondered what the "proper" way of doing so under Linux is myself.  On something like a Cisco router, you'd just create a new loopback interface ("interface loopback1").

FYI, you may want to give RFC 3484 a read for the background on "ip addrlist".

-Jim