SOLVED Freenas services page not loading properly via openvpn

[Harbicool]

Hi All

I hope someone here can help me with this issue as I'm unable to find any solution or able to identify the issue.

Recently I installed (freenas/11.1-stable) along with NextCloud 12.3 for my home LAN also set it up OpenVPN on different server ubuntu 18.04 which working fine.

I was able to access all my internal LAN resources without any issue except FreeNAS webpage and NextCloud, when I tried to access it internally it's working fine but when do the same thing via OpenVPN for both FreeNAS and NextCloud the page is not loading properly as shown below

FreeNAS Page


NextCloud not responding after enter user and password


Please let me know if there is any readings required to sort this issue.

Note: When I share folder on FreeNAS (SMB) it's working fine and I was able to upload and download files without any issue.

Thanks

 

[DrKK]

Sir,

We were just discussing your problem in the Mumble. Do you, by any chance, have a non-standard MTU? Jumbo-frames perhaps?

 

[Harbicool]

Thanks DrKK for your reply

All configured with default 1500 bytes as you can see below

Code:

											 +---------------------------------------+
											 |											   |
			   1500 MTU  (public IP)|										 em0}=============<FreeNAS / 192.168.1.10/24>
 {INTERNET} MyRouter====={ int (192.168.1.1)					  |
											 |										  eth0}=============<internal network / 192.168.1.0/24>
											 |ens33 (VMware)-(192.168.1.3)/   |
											 |	+----------------------+			 |
											 |	| iptables and		  |			 |
											 |	| routing engine	   |			 |
											 |	+--+----------------+--+		   |
											 |	   |*1				|*2			   |
											 |	 (openvpn)------------{tun0}	 |
											 |					10.8.0.1				|
											+----------------------------------------+

Interface on FreeNAS:

Code:

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
		options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
		ether 00:0c:29:b7:32:19
		hwaddr 00:0c:29:b7:32:19
		inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 <--------FreeNAS
		inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 <------- NextCloud
		nd6 options=9<PERFORMNUD,IFDISABLED>
		media: Ethernet autoselect (1000baseT <full-duplex>)
		status: active

Interface on OPENVPN server tunnel0:

Code:

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
		inet 10.8.0.1  netmask 255.255.255.255  destination 10.8.0.2
		inet6 fe80::d429:2992:7a7f:8908  prefixlen 64  scopeid 0x20<link>
		unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
		RX packets 22668  bytes 2597830 (2.5 MB)
		RX errors 0  dropped 0  overruns 0  frame 0
		TX packets 26589  bytes 27959224 (27.9 MB)
		TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

[Harbicool]

Just to confirm the frame size I tried to ping my NextCloud IP 192.168.1.11 with different MTU size fragmentation

Normal Ping:

C:\>ping 192.168.1.11

Pinging 192.168.1.11 with 32 bytes of data:
Reply from 192.168.1.11: bytes=32 time=46ms TTL=62
Reply from 192.168.1.11: bytes=32 time=38ms TTL=62
Reply from 192.168.1.11: bytes=32 time=31ms TTL=62
Reply from 192.168.1.11: bytes=32 time=46ms TTL=62

Ping statistics for 192.168.1.11:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 31ms, Maximum = 46ms, Average = 40ms

Trace route reading via tunnel (Normal):

C:\>tracert 192.168.1.11

Tracing route to 192.168.1.11 over a maximum of 30 hops

1 38 ms 23 ms 27 ms 10.8.0.1
2 39 ms 26 ms 26 ms 192.168.1.11

Trace complete.

Ping with 100:

C:\>ping -t -l 100 192.168.1.11

Pinging 192.168.1.11 with 100 bytes of data:
Reply from 192.168.1.11: bytes=100 time=40ms TTL=62
Reply from 192.168.1.11: bytes=100 time=48ms TTL=62
Reply from 192.168.1.11: bytes=100 time=52ms TTL=62
Reply from 192.168.1.11: bytes=100 time=56ms TTL=62
Reply from 192.168.1.11: bytes=100 time=40ms TTL=62

Ping statistics for 192.168.1.11:
Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 40ms, Maximum = 56ms, Average = 47ms

Ping with 1000:

C:\>ping -t -l 1000 192.168.1.11

Pinging 192.168.1.11 with 1000 bytes of data:
Reply from 192.168.1.11: bytes=1000 time=31ms TTL=62
Reply from 192.168.1.11: bytes=1000 time=43ms TTL=62
Reply from 192.168.1.11: bytes=1000 time=47ms TTL=62
Reply from 192.168.1.11: bytes=1000 time=50ms TTL=62

Ping statistics for 192.168.1.11:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 31ms, Maximum = 50ms, Average = 42ms

Ping with 1400:

C:\>ping -t -l 1400 192.168.1.11

Pinging 192.168.1.11 with 1400 bytes of data:
Reply from 192.168.1.11: bytes=1400 time=46ms TTL=62
Reply from 192.168.1.11: bytes=1400 time=49ms TTL=62
Reply from 192.168.1.11: bytes=1400 time=60ms TTL=62
Reply from 192.168.1.11: bytes=1400 time=64ms TTL=62
Reply from 192.168.1.11: bytes=1400 time=48ms TTL=62

Ping statistics for 192.168.1.11:
Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 46ms, Maximum = 64ms, Average = 53ms

Ping with Maximum size 1420:

C:\>ping -t -l 1420 192.168.1.11

Pinging 192.168.1.11 with 1420 bytes of data:
Reply from 192.168.1.11: bytes=1420 time=51ms TTL=62
Reply from 192.168.1.11: bytes=1420 time=40ms TTL=62
Reply from 192.168.1.11: bytes=1420 time=71ms TTL=62
Reply from 192.168.1.11: bytes=1420 time=47ms TTL=62
Reply from 192.168.1.11: bytes=1420 time=59ms TTL=62
Reply from 192.168.1.11: bytes=1420 time=43ms TTL=62

Ping statistics for 192.168.1.11:
Packets: Sent = 6, Received = 6, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 40ms, Maximum = 71ms, Average = 51ms

Ping with 1500:

C:\>ping -t -l 1500 192.168.1.11

Pinging 192.168.1.11 with 1500 bytes of data:
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.11:
Packets: Sent = 3, Received = 0, Lost = 3 (100% loss),

 

[DrKK]

Well I've never heard of this in my life. I couldn't even hypothesize something that would explain your symptoms, and since you sound quite competent, I am not inclined to doubt anything you've said.

Let us bring out the big guns.

@Ericloewe @joeschmuck

 

[m0nkey_]

Can you try setting mssfix 1420 within your OpenVPN server and client configurations and report back?

 

[DrKK]

Oh sorry, I missed that you could not ping at 1500.

Set the MTU on the tun lower. Allan says that should fix it straight away. Try 1400.

 

[Harbicool]

Can you try setting mssfix 1420 within your OpenVPN server and client configurations and report back?

Still the same issue

OpenVPN client Log after added mssfix 1420 from both end:
Sun Jun 17 07:02:20 2018 OPTIONS IMPORT: adjusting link_mtu to 1624

 

[Harbicool]

Oh sorry, I missed that you could not ping at 1500.

Set the MTU on the tun lower. Allan says that should fix it straight away. Try 1400.

Unfortunately still not working well


tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1400
inet 10.8.0.1 netmask 255.255.255.255 destination 10.8.0.2
inet6 fe80::2875:6d2d:204e:a45c prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 1465 bytes 132751 (132.7 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1464 bytes 1121284 (1.1 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0



I also noticed that i'm getting WARNING message in the log as below


Sun Jun 17 06:54:49 2018 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1457'
Sun Jun 17 06:54:49 2018 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1400'


 

[Harbicool]

Can you try setting mssfix 1420 within your OpenVPN server and client configurations and report back?

Have a look at this reading after applying mtu-test as this might help us to identify the correct value for mssfix


Sun Jun 17 07:39:30 2018 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
Sun Jun 17 07:42:33 2018 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1524,1471] remote->local=[1521,1471]
Sun Jun 17 07:42:33 2018 NOTE: This connection is unable to accommodate a UDP packet size of 1524. Consider using --fragment or --mssfix options as a workaround.


 

[Harbicool]

During my investigation here to isolate the issue, I captured the traffic between the client and NextCloud server and noticed a lot of [TCP Retransmission] which indicate slow or delay in the connection between the server and client.

28 10.409072 192.168.1.12 10.8.0.6 TCP 634 [TCP Retransmission] 443 → 49426 [PSH, ACK] Seq=2681 Ack=518 Win=30336 Len=580
54 16.395494 10.8.0.6 192.168.1.12 TCP 412 [TCP Retransmission] 49426 → 443 [PSH, ACK] Seq=644 Ack=3519 Win=64768 Len=358
156 17.505811 192.168.1.12 10.8.0.6 TCP 634 [TCP Retransmission] 443 → 49431 [PSH, ACK] Seq=2681 Ack=518 Win=30336 Len=580
182 17.879983 10.8.0.6 192.168.1.12 TCP 673 [TCP Retransmission] 49429 → 443 [PSH, ACK] Seq=644 Ack=3519 Win=64768 Len=619
183 17.942562 10.8.0.6 192.168.1.12 TCP 180 [TCP Retransmission] 49431 → 443 [PSH, ACK] Seq=518 Ack=3261 Win=65536 Len=126

while from the ping reading I'm getting acceptable reading with Average = 51ms response time

Any idea how to solve this issue

 

[DrKK]

I have no idea sir, I hope you get it resolved.

I hope the 51ms ping is *not* within your own LAN.

 

[Harbicool]

Thanks DrKK

Issue resolved now after I configured the NAT instead of routing (static route) to allow VPN clients access my internal LAN.

Code:

/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
/sbin/iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT

It seems that it was bouncing between the router and OpenVPN server to access my FreeNAS & Nextcloud server causing this delay.