On Mon, Aug 28, 2023 at 06:18:41PM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> On Mon, Aug 28, 2023 at 05:13:29PM +0200, p...@delphinusdns.org wrote:
> > >Synopsis: pf nat-to doesn't match a crafted packet
> > >Category: system
> > >Environment:
> > System : OpenBSD 7.3
> > Details : OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT
> > 2023
> >
> > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.arm64
> > Machine : arm64
> > >Description:
> > I was testing a seemingly valid Internet packet going out my gateway
> > but the pf firewall doesn't match nat-to to this one for some reason. I'm
> > possibly overlooking something but every other packet exiting my gateway is
> > nat'ed. What causes this? How can this be exploited?
> >
> > >How-To-Repeat:
> > Here is the tcpdump from the host 1 hop behind the NAT router:
> >
> > 16:59:08.438082 192.168.177.13 > 49.12.42.182: icmp: host 7.198.187.211
> > unreachable [icmp cksum ok] for 11.69.44.241.52699 > 7.198.187.211.55672:
> > udp 51351 [tos 0x9c] (ttl 147, id 17124, len 51419, optlen=40 NOP RR{39}=
> > RR{#106.155.117.54 233.26.79.111 129.127.249.242 60.117.146.16
> > 179.39.29.224 213.65.49.78 0.16.45.109 252.168.188.0 123.108.138.224}) (ttl
> > 64, id 65443, len 96)
> > 0000: 4500 0060 ffa3 0000 4001 ad81 c0a8 b10d E..`....@.......
> > 0010: 310c 2ab6 0301 55aa 0000 0000 4f9c c8db 1.*...U.....O...
> > 0020: 42e4 0000 9311 c756 0b45 2cf1 07c6 bbd3 B......V.E,.....
> > 0030: 0107 2704 6a9b 7536 e91a 4f6f 817f f9f2 ..'.j.u6..Oo....
> > 0040: 3c75 9210 b327 1de0 d541 314e 0010 2d6d <u...'...A1N..-m
> > 0050: fca8 bc00 7b6c 8ae0 cddb d978 0000 0000 ....{l.....x....
> >
> > and here is the tcpdump on the pppoe interface:
> >
>
> can you check there is a state in pf(4) matching ICMP dest unreachable
> packet?
>
> in order to handle icmp unreachable message there must be matching
> state in pf(4).
>
> refer to pf_test_state_icmp() where translation of ICMP error messages
> happens.
>
> hope it helps
> regards
> sashan
>
Hi Alexandr,
root@stern# tcpdump -v -n -i pppoe0 -c 1 icmp && pfctl -ss -v | grep icmp
tcpdump: listening on pppoe0, link-type PPP_ETHER
18:25:34.273661 192.168.177.13 > 49.12.42.182: icmp: host 7.198.187.211
unreachable [icmp cksum ok] (ttl 63, id 60642, len 96)
root@stern#
No state. Though it's weird that this packet makes it out despite?
Is it supposed to work this way? As far as I understand it the packet made
it to the link layer on its way out and pf doesn't stop it there any more.
Here is my icmp rulesets:
root@stern# grep icmp /etc/pf.conf
pass in on pppoe0 inet proto icmp all icmp-type 8 code 0 keep state
pass out on $port1 inet6 proto icmp6 all keep state
pass in on $port1 inet proto icmp from 192.168.177.10 to any keep state
pass in on $port1 inet proto icmp from any to any icmp-type 8 code 0
keep state
pass in on $port1 inet proto icmp from any to any icmp-type 3 code 1
keep state
pass out log (all) on vlan4 inet proto icmp all
pass in log (all) on vlan4 inet proto icmp all
port1 is the ethernet interface facing my LAN (bse0).
Best Regards,
-peter
--
Over thirty years experience on Unix-like Operating Systems starting with QNX.
