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


Reply via email to