PPPoE MTU #3328
Comments
|
which icmp response would that be for IPv4? for IPv6 there's a type response containing it's mtu (https://tools.ietf.org/html/rfc4443#section-3.2) used for PMTU, I don't know of a version for IPv4. |
|
As per my example IPv4 - https://tools.ietf.org/html/rfc1191 This is the ICMP Type it should send back - https://tools.ietf.org/html/rfc792 |
|
maybe this https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220351 give you some pointers. I'm not entirely sure this can work the way you expect. |
|
I am pretty sure that PFSense does this, I will spin up a new instance and try. This in all honesty is a basic network mechanism. |
|
Verified that this works as expected in pFsense 2.4.4p1 (No other change to my network other than the VM running pfSense instead of OPNSene). dhunt@Debian:~$ ping -s 1464 -M do 192.231.203.132 dhunt@Debian:~$ ping -s 1465 -M do 192.231.203.132 13:59:17.263941 IP 192.168.201.201 > 192.231.203.2: ICMP echo request, id 15236, seq 1, length 1472 Note the ICMP message when I up the ping size to 1465 .. and the tcpdump output reflecting the message I get back from my pfSense firewall VM (192.168.201.222). Can you fix this on OPNSense? |
|
can you compare mtu sizes on all interfaces on both systems and compare the output of |
|
vmx0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 vmx3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 [2.4.4-RELEASE][dhunt@fw1.local]/home/dhunt: grep -r scrub /tmp/rules.debug vmx1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1492 vmx0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 dhunt@fw1:~ % grep -r scrub /tmp/rules.debug |
|
a bit of context might probably help, settings are obviously differ between both, but I'm not going to guess what is what here. you can configure scrubbing at I don't expect anything needs fixing other then using the proper configuration, but if you can tell us what we should fix where, I'll happily look into it. I can't spare more time in figuring our why your specific setup doesn't work. Same message in similar circumstances (lan package doesn't fit wan's size and not using mss) from my machine using OPNsense: |
|
Context: Internal interface where client is pinging from MTU 1500 by default for Ethernet: External interface supporting PPPoE session: Routed interface where ping target is with MTU 1492 set by default: Output as requested from pfSense OPNSense config: vmx1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1492 Internal interface where client is pinging from MTU 1500 by default for Ethernet: Routed interface where ping target is with MTU 1492 set by default: Output as requested from OPNSense - this MSS is not set by me! What I expect to be fixed is that when the system assumes PPPoE is running at 1492 (which is totally fair and what pFSense does), that once the LAN side client attempt to send a packet out the PPPoE interface the system responds back with the ICMP message (too big) I have presented in the packet trace previously by default, i.e it is part of the default configuration of the firewall, as it stands this is a broken implementation. I have no idea where the 1420 MSS came from either, I have 1460 set in my config. |
|
Hi djhau, |
|
No this never got resolved! I gave up fighting this and went back to pFSense, which "just works". |
|
Over the last few days I’ve tried using IPSec vti, this has seemed to solve my problems at least. But when I switch back to using the phase 2 tunnels the traffic doesn’t pass.
Intriguingly I have 6 other IPSec tunnels on my opnsense box that work as before the upgrade, it just effects new IPSecs!
…Sent from my iPad
On 10 May 2019, at 22:42, djhau ***@***.***> wrote:
No this never got resolved! I gave up fighting this and went back to pFSense, which "just works".
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
https://forum.opnsense.org/index.php?topic=11993.msg58684;topicseen#msg58684 Is this the same issue? I can have a look next week in a quite moment. |
|
Yes but only with traffic passed over IPSec. I found nothing suspicious in rules.debug, scrubbing was enabled on all interfaces.
On building a none vti tunnel, traffic would pass for about 5-7 seconds before stopping.
Packet captures on both ends looked normal.
Switching to a vti tunnel worked but only in one direction. Luckily it was the direction we needed.
If you have any more questions I’ll help as much as I can
Many thanks
…Sent from my iPhone
On 11 May 2019, at 07:19, Michael ***@***.***> wrote:
https://forum.opnsense.org/index.php?topic=11993.msg58684;topicseen#msg58684
Is this the same issue? I can have a look next week in a quite moment.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@mimugmail it's quite easy to test/check, the "this MSS is not set by me" is explained in the help text at the interface (value set minus 40), fiddling in detail or totally disabling scrubbing can be done from Lines 579 to 595 in ab75fbb It just works in this case means, defaults are different and settlings might be too in this case. |
|
Don't know if this is relevant, but after doing to 19.1.9, PPPoE Jumbo Frames seem to be broken. 1508 (1500). |
|
I fixed mine by un-ticking "Prevent interface removal" |
|
This issue has been automatically timed-out (after 180 days of inactivity). For more information about the policies for this repository, If someone wants to step up and work on this issue, |
|
Can this issue please reopened? We have the same problem, that no icmp packet too big messages is send by opnsense if the mtu of a client in the network is bigger than 1492. So I have to set the mtu at every client manually. |
|
I have same issue as well on OPNsense 21.7.5-amd64. Disabling interface scrub did not help. |
|
@pallebone Hi Peter, should be the same as #5285 -- can you check? |
|
Hi there, I am also affected by that issue, however I cant seem to fix it by following the instructions in #5285. It is not clear to me why editing the parent interface mtu worked for him but not for me. I am continuing to check things but havent found a solution yet. They do seem related this issue and that one. Pete |
I have noticed recently that with OPNSense I don't get ICMP packet too big messages when sending DF marked packets out the WAN interface.
Setup as follows:
Client on LAN side sending ping tests out via PPPoE interface.
*** Firewall passing traffic as expected at 1492 MTU **
dhunt@Debian:~$ ping -s 1464 -M do 150.101.32.161
PING 150.101.32.161 (150.101.32.161) 1464(1492) bytes of data.
1472 bytes from 150.101.32.161: icmp_req=1 ttl=249 time=6.65 ms
1472 bytes from 150.101.32.161: icmp_req=2 ttl=249 time=9.91 ms
1472 bytes from 150.101.32.161: icmp_req=3 ttl=249 time=6.70 ms
1472 bytes from 150.101.32.161: icmp_req=4 ttl=249 time=6.72 ms
1472 bytes from 150.101.32.161: icmp_req=5 ttl=249 time=7.14 ms
1472 bytes from 150.101.32.161: icmp_req=6 ttl=249 time=6.79 ms
*** No ICMP packet too big messages received for packets that are too big to pass***
dhunt@Debian:~$ ping -s 1465 -M do 150.101.32.161
PING 150.101.32.161 (150.101.32.161) 1465(1493) bytes of data.
^C
--- 150.101.32.161 ping statistics ---
14 packets transmitted, 0 received, 100% packet loss, time 13103ms
dhunt@Debian:~$
Expect to get ICMP messages from OPNSense back to client reflecting correct MTU of the interface.
OPNSense 19.1.3
VMWare ESXI 6.7.0
VMSwitch and interface set to MTU 1500
CPU E5-2430 0 @ 2.20GHz
NIC - Broadcom BCM 5720
The text was updated successfully, but these errors were encountered: