IPFire weird behaviour with standard MTU ( fragmentation )

Virtual Private Networks IPsec
1

Hello, I have create a IPSec VPN between two IPFire this is working…
but when I do a ping to the other site of the VPN like:
Pinging 10.0.0.138 with 32 bytes of data:
Reply from 10.0.0.138: bytes=32 time=15ms TTL=62
Reply from 10.0.0.138: bytes=32 time=15ms TTL=62
Reply from 10.0.0.138: bytes=32 time=15ms TTL=62
Reply from 10.0.0.138: bytes=32 time=15ms TTL=62
this is working.

When I do a ping with more data in it like:
Pinging 10.0.0.138 with 65500 bytes of data:
Request timed out.
Request timed out.
Request timed out.

It seems that the IPFire not can handle to match data!!

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

C:\Users\Netinium>ping 10.0.0.138 -l 6550
Pinging 10.0.0.138 with 6550 bytes of data:
Reply from 10.0.0.138: bytes=6550 time=16ms TTL=62
Reply from 10.0.0.138: bytes=6550 time=17ms TTL=62
Reply from 10.0.0.138: bytes=6550 time=16ms TTL=62
Reply from 10.0.0.138: bytes=6550 time=16ms TTL=62

Is this a bug or must I do something to handle more data through the firewall

2

The page below may be initially helpful:

Regards

1 Like
3

On the two IPFire have all the nic’s MTU 1500

4

Way Can I ping/trace an Ip address through a IPsec firewall (IPFire) and also
do an telnet 10.0.0.138 4848 and my cursor is gone so the connection on port 4848 is open.
On both site is a firewall rule that all ports are open.
But in the browser on https://10.0.0.138:4848 noting happens.
what’s wrong?

5

You could have a fragmentation problem along your tunnel, regardless of the capability of the two end points. To understand the problem, you should read the first few pages of this document (or some equivalent explanation).

What happens if you ping like this?

ping other_end_of_the_tunnel -l 1472 -f

the -f says: do not fragment. The -l equal 1472 is testing the MTU size of 1500 (accounting for 8-byte ICMP header and 20-byte IP header). If you have a fragmentation problem you should have the pings not working and a specific error message, e.g: Packet needs to be fragmented but DF set. If that’s the case you can determine empirically the best MTU, as described in the link posted by @tphz

3 Likes
6

C:\Users\user>ping 10.0.0.138 -l 1472 -f

Pinging 10.0.0.138 with 1472 bytes of data:
Reply from 192.168.32.254: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 10.0.0.138:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),

7

you have a fragmentation problem. You need to change accordingly the MTU. Do an empirical test until you see no fragmentation happening, then set the two end points to that value.

2 Likes
8

C:\Users\user>ping 10.0.0.138 -l 1400 -f

Pinging 10.0.0.138 with 1400 bytes of data:
Reply from 10.0.0.138: bytes=1400 time=16ms TTL=62
Reply from 10.0.0.138: bytes=1400 time=15ms TTL=62
Reply from 10.0.0.138: bytes=1400 time=19ms TTL=62
Reply from 10.0.0.138: bytes=1400 time=15ms TTL=62

Ping statistics for 10.0.0.138:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 19ms, Average = 16ms

9

didn’t help. still can’t get to the website :hot_face:

C:\Users\user>curl -v 10.0.0.138:4848

  • Trying 10.0.0.138:4848…
  • Connected to 10.0.0.138 (10.0.0.138) port 4848 (#0)

GET / HTTP/1.1
Host: 10.0.0.138:4848
User-Agent: curl/7.83.1
Accept: /

  • Mark bundle as not supporting multiuse
    < HTTP/1.1 302 Found
    < Location: https://10.0.0.138:4848/
    < Date: Mon, 28 Nov 2022 16:14:11 GMT
    < Content-Length: 0
    < X-Frame-Options: SAMEORIGIN
    <
  • Connection #0 to host 10.0.0.138 left intact
10

You need to change the MTU at both ends of the tunnel.
In /etc/sysconfig/rc.local:

/sbin/ip link set mtu 1400 dev green0

Edit: 1400, not 1450.

11

Oke, I changed it in the IPSec Settings in the web gui
oke aim going to do that.

12

I have no file that called rc.local

13

you might need to change also the MTU of the network card assigned to the red interface. I am not sure.

1 Like
14

That is strange, it should be there.

15

Sorry looked on the wrong server

16

I have changed all the MTU to 1400 on every Nic and it WORKS thank you very very much.

1 Like
17

Happy it is working now.

Can you or a moderator include in the title the words “VPN”, “fragmentation” and “MTU” to make this thread easier to find by keyword search?

1 Like
18

Done. :wink:

BTW: This is just another case to recall the basic fact about networks. The properties of a network connection are determined by each node on the way. Especially speed and frame size ( MTU ).

3 Likes