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