Re: [gentoo-user] what about my routing here ...
Am 10.10.2013 06:45, schrieb Adam Carter: 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 So I would have to check that on the router? Or both? Just will check both, sure ... Could this lead to mislead keepalive packets from libvirtd? Maybe I should ask their network-admins for more details ... huge company, unknown structures ;-) Thanks, Stefan
Re: [gentoo-user] what about my routing here ...
On the ipfire router. A quick google turns up commands like: ip route get IP and ip route list cache match IP and if a redirected route exists, it is labelled that way in the output of such commands. If this is happening, it will be triggered by any traffic is forwarded to 10.96.25.1. Also, it shouldnt cause any problems. Other than a traceroute output not quite being what you expect, is there any problem? If everything's good dont worry about it (unless your curiosity is piqued). On Thu, Oct 10, 2013 at 5:26 PM, Stefan G. Weichinger li...@xunil.atwrote: Am 10.10.2013 06:45, schrieb Adam Carter: 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 So I would have to check that on the router? Or both? Just will check both, sure ... Could this lead to mislead keepalive packets from libvirtd? Maybe I should ask their network-admins for more details ... huge company, unknown structures ;-) Thanks, Stefan
Re: [gentoo-user] what about my routing here ...
Am 10.10.2013 10:30, schrieb Adam Carter: On the ipfire router. A quick google turns up commands like: ip route get IP and ip route list cache match IP and if a redirected route exists, it is labelled that way in the output of such commands. If this is happening, it will be triggered by any traffic is forwarded to 10.96.25.1. Also, it shouldnt cause any problems. Other than a traceroute output not quite being what you expect, is there any problem? If everything's good dont worry about it (unless your curiosity is piqued). Unfortunately not everything is good. I get strange timeouts for libvirt connections and also for scp ... what is special is that I can ssh the servers there quite stable ... same VPN, same config. For example I try to scp a small regfile: Authenticated to 10.96.25.130 ([10.96.25.130]:22). debug1: HPN to Non-HPN Connection debug1: Final hpn_buffer_size = 2097152 debug1: HPN Disabled: 0, HPN Buffer Size: 2097152 debug1: channel 0: new [client-session] debug1: Enabled Dynamic Window Scaling debug1: Entering interactive session. debug1: Sending command: scp -v -t -- /tmp Sending file modes: C0644 6943 sgw.reg Sink: C0644 6943 sgw.reg sgw.reg 100% 6943 6.8KB/s 6.8KB/s 00:00 debug1: client_input_channel_req: channel 0 rtype keepal...@openssh.com reply 1 debug1: client_input_channel_req: channel 0 rtype keepal...@openssh.com reply 1 debug1: client_input_channel_req: channel 0 rtype keepal...@openssh.com reply 1 Received disconnect from 10.96.25.130: 2: Timeout, your session not responding. lost connection I even downgraded to openssh-5.9 here just to rule out the unstable 6.2 (with 6.2 I am not even able to ssh ...) I just wrote my related questions to my contact there and wait for him to forward them to the internal network admins. Maybe the routing back to their IPSEC-gw is flaky or something ... S
[gentoo-user] what about my routing here ...
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
Re: [gentoo-user] what about my routing here ...
On 10/09/2013 06:50 AM, Stefan G. Weichinger wrote: Any hints on this? I need a vacation, btw ;-) What's on 10.96.25.2?
Re: [gentoo-user] what about my routing here ...
Am 09.10.2013 14:42, schrieb Michael Orlitzky: On 10/09/2013 06:50 AM, Stefan G. Weichinger wrote: Any hints on this? I need a vacation, btw ;-) What's on 10.96.25.2? I don't have any idea ... this out of my scope ... some upstream machine maintained by someone else.
Re: [gentoo-user] what about my routing here ...
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
