|
IPv4 and IPv6 routing issues
![[no]](/s/countries/no.gif) Shadow Hawkins on Thursday, 12 January 2012 00:10:12
I am having an issue, which is really not a problem (at least not to the best my knowledge)
Setup:
Home router (ubuntu x86 njord.l41.aconsult.no) has 2 NICS. One of which is connected to a cable modem with native dynamically assigned ipv6 and ipv4 (only one address). The other one is connected to my LAN.
Remote "router" (ubuntu x64 tyr.dp.aconsult.no) (actually not its primary function) is located at a co-location data center with only one NIC. This has statically assigned ipv4 and ipv6 addresses.
These two are connected with openvpn.
A friend of me is announcing a /24 on his router (my remote routers' gateway) and routing some parts of this to me. I am using parts of it as link-nets for openvpn and I have routed a /28 to my house, where my home router is.
The issue is as following:
In the following traceroute. My server at home is not replying with its vpn-link-net-ip, but rather the gw in the main routing-table thus replying directly on the cable-modem interface. This looks stupid in the traceroute, and might confuse remote hosts. Any thoughts on how i can get my box to reply on the desired interface (tun or tap)?
Why am i asking this on an ipv6 forum? Because the setup is exactly the same on ipv6, other than i am using a /48 from SixXS rather than ipv6 addresses announced by my friend. I have therefore no reason to believe that my router at home will change its behavior. I also believe that a discussion regarding source-routing might be of interest and relevance to other users of SixXS.
Appendix:
Traceroute from a server located in the institute of informatics at the university of Oslo. Connected to uninett (Norwegian equivalent of German DFN, for those of you more familiar with this). Uninett has some aversions to portlane, l3 and cogent. Hence not peering with them (at least not at nix1). And my friend is not peering with telia at digiplex (co-location datacenter). This gives for a ridiculous path from there to my server (Via Sweden, Germany and Denmark (MPLS!?) back to Oslo)
1 ifi-gw21.uio.no (129.240.65.253) 0.419 ms 0.449 ms 0.490 ms
2 uio-gw21.uio.no (129.240.24.249) 0.474 ms 0.512 ms 0.573 ms
3 uio-gw8.uio.no (129.240.24.253) 0.358 ms 0.429 ms 0.477 ms
4 oslo-gw.uninett.no (128.39.65.17) 0.322 ms 0.480 ms 0.620 ms
5 se-tug.nordu.net (109.105.102.21) 8.002 ms 8.033 ms 8.087 ms
6 s-b4-link.telia.net (213.248.97.93) 24.844 ms 24.051 ms 22.717 ms
7 s-bb1-link.telia.net (80.91.246.148) 8.265 ms 8.254 ms 8.232 ms
8 ffm-bb1-link.telia.net (80.91.248.53) 110.294 ms 110.286 ms 110.280 ms
9 ffm-b12-link.telia.net (80.91.246.117) 32.963 ms ffm-b12-link.telia.net (213.155.130.146) 32.891 ms ffm-b12-link.telia.net (213.155.130.148) 35.463 ms
10 cogent-ic-140550-ffm-b12.c.telia.net (213.248.103.106) 35.728 ms 35.750 ms te0-3-0-7.ccr21.fra03.atlas.cogentco.com (130.117.14.169) 35.856 ms
11 te0-3-0-4.ccr21.ham01.atlas.cogentco.com (130.117.49.242) 42.877 ms 42.846 ms 42.974 ms
12 te3-2.ccr01.osl01.atlas.cogentco.com (130.117.2.178) 57.852 ms 57.845 ms 57.905 ms
13 154.54.60.138 (154.54.60.138) 63.089 ms 58.538 ms 154.54.60.142 (154.54.60.142) 61.091 ms
14 cogent-gw.blixbone.net (149.6.116.98) 30.533 ms 30.486 ms 30.346 ms
15 ge162.link.blixbone.net (178.255.145.162) 30.595 ms 30.590 ms 30.525 ms
16 gw.sygard.no (178.255.145.74) 38.721 ms 38.763 ms 38.830 ms
17 tyr.dp.aconsult.no (91.213.127.6) 38.735 ms 38.926 ms 38.719 ms
18 99.177.251.212.customer.cdi.no (212.251.177.99) 38.745 ms 40.986 ms 40.248 ms
19 urd.l41.aconsult.no (91.213.127.147) 48.651 ms 47.291 ms 48.492 ms
IPv4 and IPv6 routing issues
My server at home is not replying with its vpn-link-net-ip, but rather the gw in the main routing-table thus replying directly on the cable-modem interface.
You need to setup source routing to resolve this. As with any kind of routing issue, providing full interface and routing tables that are involved is very useful.
This looks stupid in the traceroute, and might confuse remote hosts.
Not only that, you should not be able to source that address over that interface. See BCP38.
Clearly some network allows spoofing while it should not. Please fix that ASAP.
I also believe that a discussion regarding source-routing might be of interest and relevance to other users of SixXS.
While source routing is the proper solution. I tend to state that having two links with different prefixes and trying to load-balance or similar kind of things over that is a bad setup, very complex and has too many failure scenarios. While it can work, when one of the links breaks that prefix is unavailable and thus useless. As such, it is not a scenario that makes much sense.
Now if you had two IPv4 links and then used heartbeat/ayiya over that letting the packets go over on link as long as it is active and switch to the backup when the primary fails, then that could work. Of course you would still then be at mercy of PoP failures that might happen. If you do this, please do not switch endpoints every second, that is not nice for the PoP and it will actually automatically disable your tunnel as your endpoint is noted as flapping.
IPv4 and IPv6 routing issues
Shadow Hawkins on Thursday, 12 January 2012 20:18:15You need to setup source routing to resolve this.
Is it possible to manage with ip rules? Or does the traceroute reply invoke rules that suppresses the ip rules at hand?
0: from all lookup local
32764: from 91.213.127.144/28 lookup tun-tyr
32765: from 91.213.127.128/29 lookup tun-tyr
32766: from all lookup main
32767: from all lookup default
Main routing table
91.213.127.128/29 dev tap0 proto kernel scope link src 91.213.127.130
91.213.127.144/28 dev eth0 proto kernel scope link src 91.213.127.145
212.251.177.0/24 dev eth1 proto kernel scope link src 212.251.177.99
default via 212.251.177.1 dev eth1 metric 100
tun-tyr routing table
91.213.127.128/29 dev tap0 scope link
91.213.127.144/28 dev eth0 scope link
default via 91.213.127.129 dev tap0
ip addr (lo omitted) 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNO WN qlen 1000
link/ether 00:0a:5e:04:f2:bb brd ff:ff:ff:ff:ff:ff
inet 212.251.177.99/24 brd 212.251.177.255 scope global eth1
inet6 fe80::20a:5eff:fe04:f2bb/64 scope link
valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:14:22:33:81:80 brd ff:ff:ff:ff:ff:ff
inet 91.213.127.145/28 brd 91.213.127.159 scope global eth0
inet6 fe80::214:22ff:fe33:8180/64 scope link
valid_lft forever preferred_lft forever
6: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNO WN qlen 100
link/ether 36:87:af:bd:dd:72 brd ff:ff:ff:ff:ff:ff
inet 91.213.127.130/29 brd 91.213.127.135 scope global tap0
inet6 fe80::3487:afff:febd:dd72/64 scope link
valid_lft forever preferred_lft forever
I tend to state that having two links with different prefixes and trying to load-balance or similar kind of things over that is a bad setup, very complex and has too many failure scenarios
I agree with that on a principle basis, at least in a full IP-Scheme. And my setup employs only one wan adapter, and the intent is to route all traffic over the vpn.
If you do this, please do not switch endpoints every second, that is not nice for the PoP and it will actually automatically disable your tunnel as your endpoint is noted as flapping.
I am planning on deploying the tunnel at a static end point (tyr.dp.aconsult.no) so i have no plans on invoking this state.
IPv4 and IPv6 routing issues
0: from all lookup local
Looks to me like that is your primary rule and thus that matches everything, you might want to kick that one out.
IPv4 and IPv6 routing issues
Shadow Hawkins on Thursday, 12 January 2012 22:02:09
It actually iterates over all of them, so it works fine.
The solution was to make a /32 route to the remote vpn server via the gw on the cable company network, then change the default route to go over the remote vpn via the tap adapter.
Given that its dhcp, dhclient has to be run with a startup script that deletes the default route, and isolates the gw and putting it into the /32 route. Not very intricate, and the reachability problems are solved. As well as making for a pretty traceroute.
But thanks for the help, so far :)
|
![[ch]](/s/countries/ch.gif)
on Thursday, 12 January 2012 13:21:50
Posting is only allowed when you are