No connection to remote network through VPN

razupaltuff · March 18, 2019, 5:42pm

Hi all,

after the installation of the current OpenWRT 18.06.2 everything works fine, except...

I'm not able to establish any connection (http or rdp) to a device in another network anymore. The other network is accessed through a (local established) VPN connection. The tunnel could be established and is stable.
A http-connection is not possible, a RDP-connection neither. The strange thing with the RDP-connection is, that the credentials are accepted and the first screen (of windows) appears, but then... Nothing happens.

I hope anyone has an idea...

Some information to my setup at the end:
Local Network: 192.168.1.0/24
Remote Network: 172.22.33.0/24
VPN: IPSec/Xauth (Fritzbox)
Router: Fritzbox 7360v1 with DSLite, no changes to the default firewall

Thanks a lot in advance!

lleachii · March 18, 2019, 6:12pm

At no point did you describe the VPN's config

Is this VPN on your client, or the OpenWrt router?

razupaltuff · March 18, 2019, 6:35pm

Oh, I'm sorry.

Which information of the VPN configuration do you need in particular? It is an IPSec/XAuth VPN with PSK. The route to the remote network is set.
The VPN is established on my clients (Linux, Android, ShrewSoft)

Schema:

Computer -- OpenWrt -- Internet -- FritzBox -- Computer
Me - VPN ------------------------------> FritzBox

Summed up:

Setup worked before OpenWRT
a ping to the remote computers work
http connection doesn't
rdp connection only works until successful authentication

Thanks

lleachii · March 18, 2019, 6:37pm

I'm lost...how is the OpenWrt involved if IPSec is installed on the clients?
Is your firewall having issues?
I'm confused about the 3 routers
Did you try connecting a client directly to your WAN and testing?

razupaltuff · March 18, 2019, 6:48pm

Thats my question as well... I only changed one component: Upgrading my FritzBox to OpenWRT.

It's my guess. But I've no idea how OpenWRT should prevent a rdp or http-connection in the tunnel.

My firewall-config:

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option syn_flood '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	option network 'wan6 wan4 wan'

config forwarding
	option src 'lan'
	option dest 'wan'

config include
	option path '/etc/firewall.user'

3? Only two (one FritzBox on my Side (with OpenWRT) and one on the other). The second line should only display the connection...

No, but I've reverted the FritzOS and anything works again... Is this enough testing?

vgaetera · March 18, 2019, 6:56pm

May be incorrect interface to zone binding so rules Allow-IPSec-ESP and Allow-ISAKMP don't work properly.

uci show network

razupaltuff · March 18, 2019, 8:03pm

The bindings in luci and also in the firewall-config look fine (imo).

The output of uci show network:

network.loopback=interface
network.loopback.ifname='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.globals=globals
network.globals.ula_prefix='fdb6:f5a6:d80d::/48'
network.atm=atm-bridge
network.atm.vpi='1'
network.atm.vci='32'
network.atm.encaps='llc'
network.atm.payload='bridged'
network.atm.nameprefix='dsl'
network.dsl=dsl
network.dsl.annex='b'
network.dsl.tone='av'
network.dsl.line_mode='adsl'
network.dsl.ds_snr_offset='0'
network.lan=interface
network.lan.type='bridge'
network.lan.ifname='eth0.1'
network.lan.proto='static'
network.lan.ipaddr='192.168.1.1'
network.lan.netmask='255.255.255.0'
network.lan.ip6assign='60'
network.wan=interface
network.wan.proto='pppoe'
network.wan.username='XXXXXXX@XXXXXXX'
network.wan.password='XXXXXXX'
network.wan.ifname='dsl0.40'
network.wan.peerdns='0'
network.wan.delegate='0'
network.wan.ipv6='1'
network.wan_dev=device
network.wan_dev.name='dsl0'
network.wan_dev.macaddr='XX:XX:XX:XX:XX:XX'
network.@switch[0]=switch
network.@switch[0].name='switch0'
network.@switch[0].reset='1'
network.@switch[0].enable_vlan='1'
network.@switch_vlan[0]=switch_vlan
network.@switch_vlan[0].device='switch0'
network.@switch_vlan[0].vlan='1'
network.@switch_vlan[0].ports='0 1 2 4 6t'
network.@switch_vlan[0].vid='1'
network.wan4=interface
network.wan4.proto='dslite'
network.wan4.peeraddr='XXXX:XXX:X:X::ffff'
network.wan4.force_link='1'
network.wan4.tunlink='wan'
network.wan6=interface
network.wan6.proto='dhcpv6'
network.wan6.reqprefix='auto'
network.wan6.ifname='@wan'
network.wan6.force_link='1'
network.wan6.delegate='0'
network.wan6.reqaddress='try'

mpa · March 18, 2019, 9:47pm

Could you please reduce the MTU on your client's ethernet or VPN interface for testing?
1000 bytes should be fine.

razupaltuff · March 19, 2019, 2:39pm

Thanks for your replies so far!

Does not help

My current guess is, that the problem is hidden anywhere inside the routing of my devices... My knowledge about this is not very good, but is it possible that route-autodetection of the tunnel is affected by the router?
Things, that make me think about:

if the tunnel is enabled, no connection to the internet is possible
the initial connection always works:
- if I access a http-Website (inside the remote network), the BasicAuth works fine but nothing else
- as mentioned before, the authentication of the rdp-connection works too
ssh-connections are working
ping is working

If anyone has a suggestion what to try next... This would be great

trendy · March 19, 2019, 4:21pm

Sounds like mtu.
From the computer behind openwrt can you ping the other computer behind fritz with don't-fragment option and various payload sizes? By default the payload is 32 or 64 bytes so work your way up to see where it will stop replying.

razupaltuff · March 19, 2019, 5:23pm

What a shame! I changed it, but after establishing the connection the mtu has been changed again (back to the old value...). Note to myself: Always do a double check
Now it works.

Strange anyway that I need here some modifications on my client(s) which I did not need before.

Many thanks to all of you!

mpa · March 19, 2019, 10:35pm

Now you can try increasing the MTU value again to find the maximum that still works.
I recommend at least 1280 bytes if possible, since this is the minimum required for IPv6.
I am sorry for not proposing this value from the beginning.

Ideally, the MTU value would be determined by the Path MTU Discovery technique, which relies on an ICMP message to report an oversized packet. If a middlebox blocks these ICMP messages, Path MTU Discovery breaks. DSLite has two such middleboxes which could interfere: your own router, and the NAT gateway at your ISP.

Reducing the MTU administratively is not an ideal solution. How could you improve it?

Ask your ISP for dual-stack instead of DSLite. Your router would get a public IPv4 address and there would be no extra NAT or tunneling imposed by your ISP.
If the peer gateway has IPv6 connectivity, run the VPN tunnel over IPv6. However, this is not supported by FritzOS; it is only an option if you can replace the hardware or firmware of the remote gateway.

system · March 29, 2019, 10:35pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.