New NBN connection, some traffic appears to be filtered

[adrian1]

Hi, I've had my internet connection with TPG for many years at several addresses and this is the first time I'm seeing this. Browsing works, ping works, everything appears to be fine, yet I can't connection to my wireguard VPN and to some addresses SSH connection hangs after the authentication. Example for the ssh connection:

debug1: Authentication succeeded (publickey).
Authenticated to xx.xx.xx.xx ([xx.xx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: cert: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: principals: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: cert: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: principals: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = en_AU.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

At this point the ssh client tries to send packets through the ssh tunnel, but I don't see any traffic at the xx.xx.xx.xx server end.

For wireguard looks like this: the client tries to the server, but the server doesn't see any packets from my end. *However* and this is important information: if, instead of trying the wireguard client, I try a netcat session like this:

nc -vv -u xx.xx.xx.xx xxxxx

where xxxxx is the wireguard port, I can see packets on the server end coming from my public IP, which are obviously ignored by wireguard. So the IP part seems to work, but perhaps some traffic inspection is set up somewhere that prevents my ssh and wireguard sessions to work(?)

I've never had this problem before, everything used to work, including on my previous NBN HFC connection.

The modem is a "TP-Link Hardware Version:VX420-G2v v1.0 00000000 " and I'm on an "NBN Business XL Bundle Fast with static IP" and I need everything to work, my ability to do my job relies on an unfiltered internet connection.

Thanks, Adrian

[david64]

Hi @adrian1 . There are a couple of other users here with ssh problems; getting broken pipe. Do search on ssh or ipqos.

Can you try    -o IPQoS=0    in ssh command or add parameter to one of the ssh config files.

[adrian1]

Thanks, this config option seems to do the trick for ssh, much appreciated! Now I have to figure out why this is needed and why isn't my Wireguard VPN not working. Will keep everyone updated. Thanks again

[david64]

@adrian1 . Did you have the VX420 on your previous HFC connection? Or, has the problem only started since getting it?

(If you have another router, try it in place of VX420.)

Are you familiar with packet capture software, eg. Wireshark? If you have access at server end, you could check correlation between the value used for IPQoS in ssh and the received packet at server end. Do some values cause session to drop out?

Is port forwarding involved?

[adrian1]

@david64the problem started on the new NBN connection. Previously I had ADSL, then NBN HFC and now NBN FTTN at a different address in a different state. I'll try to fiddle with DSCP and see what results I'm getting for various values. Thanks.

[adrian1]

The following values for IPQoS work: cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, reliability, none. For every other value the SSH connection hangs and terminates with broken pipe eventually.

For Wireguard clearing DSCP bits with

iptables -t mangle -A POSTROUTING -d wg.server.ip -j DSCP --set-dscp 0

seems to do the trick. But my ssh connections and other VPN traffic looks slower than before.

@david64 thanks again, I'll need to take this up with TPG because the connection is unnacceptable in the current state. It's supposedly a business connection but can barely be used for the purpose!

[adrian1]

Setting MTU=1400 in the wireguard client config, [Interface] section, helps with the latency on the VPN tunnel.