There might have been a icmp redirect from 10.96.25.1 telling ipfire that there's a better way to get to that network, and its via 10.96.25.2.
On my system it seems to be off by default (I havent set it in /etc/sysctl.conf) which makes sense as redirects can be used for MITM attacks. $ cat /proc/sys/net/ipv4/conf/all/accept_redirects 0 On Wed, Oct 9, 2013 at 9:50 PM, Stefan G. Weichinger <li...@xunil.at> wrote: > > server: > > # ip route s > default via 10.96.25.129 dev br0 > 10.96.25.128/25 dev br0 proto kernel scope link src 10.96.25.131 > 192.168.1.0/24 dev eno2 proto kernel scope link src 192.168.1.201 > > # !tra > traceroute 172.32.99.12 > traceroute to 172.32.99.12 (172.32.99.12), 30 hops max, 60 byte packets > 1 ipfire (10.96.25.129) 0.410 ms 1.213 ms 1.302 ms > 2 10.96.25.2 (10.96.25.2) 3.853 ms 3.835 ms 3.825 ms > > ^C > > on the router "ipfire" (which is 10.96.25.129 on its LAN-side) > > # ip r s > default via 10.96.25.1 dev blue0 > > no specific routes on there > > The route should go via 10.96.25.1 for targets in 172.32.99.0/24 as > well ... > > I don't get where it gets 10.96.25.2 from *scratch* > > This routing issue might be the problem with my libvirt-connections (see > other current thread). > > Even when I do > > # ip route add 172.32.99.12/32 via 10.96.25.1 > > on the router (explicit route for my desktop IP) the traceroute still > shows: > > # traceroute 172.32.99.12 > traceroute to 172.32.99.12 (172.32.99.12), 30 hops max, 60 byte packets > 1 ipfire.mlp-ag.com (10.96.25.129) 0.294 ms 0.270 ms 0.258 ms > 2 10.96.25.2 (10.96.25.2) 0.569 ms 0.746 ms 0.987 ms^C > > Any hints on this? > I need a vacation, btw ;-) > > And the best: I do this via ssh, so I am already connected ... which > means I get packages back ... > > S > >
