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 [email protected]
reply 1
debug1: client_input_channel_req: channel 0 rtype [email protected]
reply 1
debug1: client_input_channel_req: channel 0 rtype [email protected]
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