Project

General

Profile

Actions

Bug #14371

open

Firewall does not respond to UDP traceroute requests over IPsec

Added by Marcos M 12 months ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
Category:
IPsec
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

Tested on 23.01.

pfSense itself does not respond to UDP traceroutes when it receives the request over IPsec (both policy/routed tunnels tested, as well as with pf disabled).

In the following example, traceroute is run from a LAN client behind siteA to the LAN interface address of siteB.

### siteA client
[22.01-DEVELOPMENT][root@sitea-lanhost.lab.arpa]/root: traceroute -n -I 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 64 hops max, 48 byte packets
 1  172.19.1.1  0.337 ms  0.106 ms  0.174 ms
 2  192.168.1.1  0.684 ms  0.607 ms  0.531 ms
[22.01-DEVELOPMENT][root@sitea-lanhost.lab.arpa]/root: traceroute -n 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 64 hops max, 40 byte packets
 1  172.19.1.1  0.283 ms  0.185 ms  0.189 ms
 2  * * *
 3  * *^C

### siteB firewall
[23.01-RELEASE][root@siteb-fw1.lab.arpa]/root: ifconfig vmx1
vmx1: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: LAN
        options=4e000bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
        ether 00:50:56:b2:00:fe
        inet6 fe80::250:56ff:feb2:fe%vmx1 prefixlen 64 scopeid 0x2
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
[23.01-RELEASE][root@siteb-fw1.lab.arpa]/root: tcpdump -ni enc0 'host 172.19.1.4'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 262144 bytes
19:01:30.681093 (authentic,confidential): SPI 0xca57b541: IP 172.19.1.4 > 192.168.1.1: ICMP echo request, id 32776, seq 4, length 28
19:01:30.681173 (authentic,confidential): SPI 0xcaa92d26: IP 192.168.1.1 > 172.19.1.4: ICMP echo reply, id 32776, seq 4, length 28
19:01:30.681567 (authentic,confidential): SPI 0xca57b541: IP 172.19.1.4 > 192.168.1.1: ICMP echo request, id 32776, seq 5, length 28
19:01:30.681586 (authentic,confidential): SPI 0xcaa92d26: IP 192.168.1.1 > 172.19.1.4: ICMP echo reply, id 32776, seq 5, length 28
19:01:30.682120 (authentic,confidential): SPI 0xca57b541: IP 172.19.1.4 > 192.168.1.1: ICMP echo request, id 32776, seq 6, length 28
19:01:30.682142 (authentic,confidential): SPI 0xcaa92d26: IP 192.168.1.1 > 172.19.1.4: ICMP echo reply, id 32776, seq 6, length 28
19:01:34.226850 (authentic,confidential): SPI 0xca57b541: IP 172.19.1.4.32816 > 192.168.1.1.33438: UDP, length 12
19:01:39.310089 (authentic,confidential): SPI 0xca57b541: IP 172.19.1.4.32816 > 192.168.1.1.33439: UDP, length 12
19:01:44.388844 (authentic,confidential): SPI 0xca57b541: IP 172.19.1.4.32816 > 192.168.1.1.33440: UDP, length 12
^C
9 packets captured
242 packets received by filter
0 packets dropped by kernel

Traceroutes to other clients on the siteB LAN work fine.

Actions #1

Updated by Marcos M 11 months ago

  • Description updated (diff)
  • Assignee set to Mateusz Guzik
Actions #2

Updated by Johannes Rohde about 1 month ago

I am seeing a similar behavior on wireguard tunnels as well. You can see the incoming request in the pcap but no answer from the pfsense.

Actions

Also available in: Atom PDF