From nobody Wed Dec 07 14:33:47 2022 X-Original-To: ipfw@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NS0CY6WDnz4k06J for ; Wed, 7 Dec 2022 14:34:01 +0000 (UTC) (envelope-from john@sanren.ac.za) Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [IPv6:2001:4860:4864:20::33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NS0CX4tYmz3qvq for ; Wed, 7 Dec 2022 14:34:00 +0000 (UTC) (envelope-from john@sanren.ac.za) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sanren-ac-za.20210112.gappssmtp.com header.s=20210112 header.b=wb+CSreN; spf=pass (mx1.freebsd.org: domain of john@sanren.ac.za designates 2001:4860:4864:20::33 as permitted sender) smtp.mailfrom=john@sanren.ac.za; dmarc=none Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-144bd860fdbso8345869fac.0 for ; Wed, 07 Dec 2022 06:34:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sanren-ac-za.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=bIPMlcOc01bjRt0DBItcmD/x9D39ulrWy2OXzPZWGHs=; b=wb+CSreNsk+e/Yg61accPqqybHtnaSEtgnePT9nG4uRc2aAux1SuHEhv5OMgwb3DgM pL/Fm3F8Rtxv0/1AeL9ziW+r83K43iPb2I0EZKZGLZZih7luzUa9VECtTt8KMu594exu LJh3Gz5RctmZTTGqixZSNXq1lFf+Tc6c2+lBdBmefod0TISXKC+6CyzEhiCSdR6Iik39 +o19RlAf4YMxN4GXsPU7JV2LRqWc3bnRXE7bSbdxFNx8+72k6LgRre9i64JTJWiljTlM mgZFMoEJ180k0rr77K/4w+tobThWcTjONgueDDIymvYAcGib/0wHPQ3cSL3qQLDd8oD2 /V/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=bIPMlcOc01bjRt0DBItcmD/x9D39ulrWy2OXzPZWGHs=; b=IUlx7uW6yKbvFyDzpKjAL4N76A9GThWhdkg/ISqVCz0GgVfaoWRct4Wath9MNiTw/e E6wqMsQ5uDwoFrU1St2aLCiqpZnI97LD//ChXJDMZml2RiJsNT1Sh+cVYud116bM/xMh 3UV+COcmB0nQuorRqwi6qUNDLf4ILk+879ZGvyDi/CC0rhwjBv28DXnQLfiyDDLAk/Nr h3ByiKPTKNAgquenor3iibEpu3aqh7jks8iC+8dhKTQFF8afqfy633f1GjVcL3j9bzBy 383jOM+GknmkrzebQ5elOZj72rMs7NYMBXbqe8s2/Nb8hjPoIckE807Xr9vg3KXNJMs4 0zDQ== X-Gm-Message-State: ANoB5pnpBTm2QSPsG+JWKjXg49OD1ysLooAIAkNoJuRkLmalr+OsNHun DDdiNOl208PPrkjEf4vgxr7i++PwNjryR3r9uFZVdNGZmL8QlK7I X-Google-Smtp-Source: AA0mqf79wz4BkDm5axTBU0s3k6RV0BHrB5fwwPKrT13YlgxkJzKxFXDHJte2Xd/2EEKCHFJLpZ83Ngf76rUqW2gai3U= X-Received: by 2002:a05:6870:d90e:b0:13c:ed73:847e with SMTP id gq14-20020a056870d90e00b0013ced73847emr52522302oab.63.1670423638475; Wed, 07 Dec 2022 06:33:58 -0800 (PST) List-Id: IPFW Technical Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-ipfw List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ipfw@freebsd.org MIME-Version: 1.0 From: John Hay Date: Wed, 7 Dec 2022 16:33:47 +0200 Message-ID: Subject: ipfw nat and smaller wan mtu To: ipfw@freebsd.org Content-Type: multipart/alternative; boundary="000000000000989b7905ef3dcfbd" X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36]; R_DKIM_ALLOW(-0.20)[sanren-ac-za.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::33:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[ipfw@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[sanren-ac-za.20210112.gappssmtp.com:+]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[sanren.ac.za]; PREVIOUSLY_DELIVERED(0.00)[ipfw@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NS0CX4tYmz3qvq X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --000000000000989b7905ef3dcfbd Content-Type: text/plain; charset="UTF-8" Hi, What would the proper ipfw rules be to make nat work and properly get the icmp too big packets back to a local host if the wan interface needs a smaller mtu? I'm using a FreeBSD machine as router/firewall, but its wan interface needs a smaller mtu (1392) than the default ethernet mtu. I have replicated this in a VM so I can test it. My simplified ipfw rules make it work for packets that are smaller than the wan mtu: ##### net.inet.ip.fw.one_pass=0 net.inet.ip.fw.verbose=1 ##### fwcmd="/sbin/ipfw -q" wan="vtnet0" lan="vtnet1" ${fwcmd} nat 123 config if ${wan} log ${fwcmd} add 1000 count log all from any to any ${fwcmd} add 5000 nat 123 ip4 from any to any via ${wan} ${fwcmd} add 6000 allow log all from any to any ##### The wan ip of the firewall is 10.10.2.2 and the ip address of the host (on the lan side) I'm testing from is 10.10.1.3. And I did a ping to 10.10.5.5, which is on the other side of the wan interface. This works for packets smaller than the wan mtu. But if the packet is larger than the wan mtu, the icmp too big is generated, but with 127.0.0.1 as the source and the wan ip as the destination and then sent via lo0 and it looks like this in the ipfw log: Dec 7 13:24:59 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2 out via lo0 So I added a nat ipfw rule to catch that: ${fwcmd} add 5050 nat 123 ip4 from any to not 127.0.0.1 via lo0 That helped partly because it was then able to recover the address of the host I was testing from and tried to send the packet out on the correct interface (vtnet1). Unfortunately it still had the source address of 127.0.0.1, which means it did not actually make it to the wire: ###### Dec 7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:8.0 10.10.1.3 10.10.5.5 in via vtnet1 Dec 7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:8.0 10.10.1.3 10.10.5.5 in via vtnet1 Dec 7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:8.0 10.10.1.3 10.10.5.5 out via vtnet0 Dec 7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:8.0 10.10.2.2 10.10.5.5 out via vtnet0 Dec 7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2 out via lo0 Dec 7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.2.2 out via lo0 Dec 7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2 in via lo0 Dec 7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.1.3 in via lo0 Dec 7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.1.3 out via vtnet1 Dec 7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.1.3 out via vtnet1 ###### Once I have this sorted, there seems to be a similar problem with nptv6. Regards John --000000000000989b7905ef3dcfbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

What would the proper ip= fw rules be to make nat work and properly get the icmp too big packets back= to a local host if the wan interface needs a smaller mtu?

I'm using a FreeBSD machine as router/firewall, but its wan in= terface needs a smaller mtu (1392) than the default ethernet mtu. I have re= plicated this in a VM so I can test it. My simplified ipfw rules make it wo= rk for packets that are smaller than the wan mtu:

= #####
net.inet.ip.fw.one_pass=3D0
net.inet.ip.fw.verbose=3D1
#####
fwcmd=3D"/sbin/ipfw -q"
wa= n=3D"vtnet0"
lan=3D"vtnet1"
${fwcmd= } nat 123 config if ${wan} log
${fwcmd} add 1000 count log all fr= om any to any
${fwcmd} add 5000 nat 123 ip4 from any to any via $= {wan}
${fwcmd} add 6000 allow log all from any to any
#= ####
The wan ip of the firewall is 10.10.2.2 and the ip address o= f the host (on the lan side) I'm testing from is 10.10.1.3. And I did a= ping to 10.10.5.5, which is on the other side of the wan interface.

This works for packets smaller than the wan mtu. But= if the packet is larger than the wan mtu, the icmp too big is generated, b= ut with 127.0.0.1 as the source and the wan ip as the destination and then = sent via lo0 and it looks like this in the ipfw log:

Dec =C2=A07 13:24:59 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.= 10.2.2 out via lo0

So I added a nat ipfw rule to c= atch that:

${fwcmd} add 5050 nat 123 ip4 from any = to not 127.0.0.1 via lo0

That helped partly becaus= e it was then able to recover the address of the host I was testing from an= d tried to send the packet out on the correct interface (vtnet1). Unfortuna= tely it still had the source address of 127.0.0.1, which means it did not a= ctually make it to the wire:

######
D= ec =C2=A07 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:8.0 10.10.1.3 10.10.5= .5 in via vtnet1
Dec =C2=A07 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP= :8.0 10.10.1.3 10.10.5.5 in via vtnet1
Dec =C2=A07 14:17:31 rtr kernel: = ipfw: 1000 Count ICMP:8.0 10.10.1.3 10.10.5.5 out via vtnet0
Dec =C2=A07= 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:8.0 10.10.2.2 10.10.5.5 out vi= a vtnet0
Dec =C2=A07 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.= 0.0.1 10.10.2.2 out via lo0
Dec =C2=A07 14:17:31 rtr kernel: ipfw: 6000 = Accept ICMP:3.4 127.0.0.1 10.10.2.2 out via lo0
Dec =C2=A07 14:17:31 rtr= kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2 in via lo0
Dec = =C2=A07 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.1.3= in via lo0
Dec =C2=A07 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 1= 27.0.0.1 10.10.1.3 out via vtnet1
Dec =C2=A07 14:17:31 rtr kernel: ipfw:= 6000 Accept ICMP:3.4 127.0.0.1 10.10.1.3 out via vtnet1
######
=

Once I have this sorted, there seems to be a simi= lar problem with nptv6.

Regards

John

--000000000000989b7905ef3dcfbd--