https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269770
--- Comment #2 from Peter Much <p...@citylink.dinoex.sub.org> ---
I managed to analyze this a bit further:
With an UDP service (e.g. VPN) portforwarded behind NAT there is no notion of a
connection, and apparently it can happen that libalias creates TWO distinct
records for inbound and outbound traffic, with the inbound record lacking the
portforward (and the received packets then dumped as undeliverable on the
NATing node).
The problem always resolves itself after either 12 or 14 minutes, apparently
due to internal timings.
Observed with dtrace (cmdline is attached):
203.0.113.1 is my public address where NAT aliases to
198.51.100.1 is the address of the connecting client from outside
192.168.1.12 is the internal address of the VPN server (where portforward goes
to)
-> At this time we have a packet client->server, two server->client and another
client->server, all successful
18 17832 DeleteLink:entry openvpn 1708555176 icmp=5 udp=2
tcp=108
type=17 (src_addr 192.168.1.12) (dst_addr 0.0.0.0)
(alias_addr 0.0.0.0) (proxy_addr 0.0.0.0)
(src_port 5007) (dst_port 0) (alias_port 5006) (proxy_port 0)
-> For whatever reason libalias tries to delete some UDP, but the next line
shows that nothing was actually deleted. So this would apparently be the
permanent portforward, there is no other codepath
18 49947 AddLink:entry openvpn 1708555180 icmp=5 udp=2
tcp=108
-> At this time we get a packet client->server, and it is the first failing (it
gets processed by libalias, but NOT portforwarded (in the next second we also
get packets in the other direction, so without fractional seconds logged we
do not know when exactly what happened)
18 17832 DeleteLink:entry openvpn 1708555186 icmp=5 udp=2
tcp=111
type=17 (src_addr 192.168.1.12) (dst_addr 198.51.100.1)
(alias_addr 0.0.0.0) (proxy_addr 0.0.0.0)
(src_port 5007) (dst_port 8211) (alias_port 5006) (proxy_port 0)
-> Here the portforward got deleted (but WHY? It is continuousley used, pings
every 10 seconds), and udp count goes to 1.
18 49947 AddLink:entry openvpn 1708555186 icmp=5 udp=1
tcp=111
(src_addr 203.0.113.1) (dst_addr 91.62.14.110) (alias_addr
203.0.113.1)
(src_port 5006)
18 49948 AddLink:return openvpn 1708555186 icmp=5 udp=2
tcp=111
type=17 (src_addr 203.0.113.1) (dst_addr 198.51.100.1)
(alias_addr 203.0.113.1) (proxy_addr 0.0.0.0)
(src_port 5006) (dst_port 8211) (alias_port 5006) (proxy_port 0)
-> And immediately added again, but now WITHOUT the portforward!!
19 17832 DeleteLink:entry suricata 1708555186 icmp=5 udp=2
tcp=111
type=17 (src_addr 192.168.1.12) (dst_addr 0.0.0.0)
(alias_addr 0.0.0.0) (proxy_addr 0.0.0.0)
(src_port 5007) (dst_port 0) (alias_port 5006) (proxy_port 0)
-> Apparently the housekeeping is too aggressive...
19 49947 AddLink:entry suricata 1708555186 icmp=5 udp=2
tcp=111
(src_addr 192.168.1.12) (dst_addr 198.51.100.1) (alias_addr 0.0.00)
(src_port 5007)
19 49948 AddLink:return suricata 1708555186 icmp=5 udp=3
tcp=111
type=17 (src_addr 192.168.1.12) (dst_addr 198.51.100.1)
(alias_addr 0.0.0.0) (proxy_addr 0.0.0.0)
(src_port 5007) (dst_port 8211) (alias_port 5006) (proxy_port 0)
-> And now we get the portforward as a *SEPARATE* record (udp went to 3!)
19 17832 DeleteLink:entry suricata 1708555186 icmp=5 udp=3
tcp=111
type=17 (src_addr 192.168.1.12) (dst_addr 0.0.0.0)
(alias_addr 0.0.0.0) (proxy_addr 0.0.0.0)
(src_port 5007) (dst_port 0) (alias_port 5006) (proxy_port 0)
-> groundhog day again
--
You are receiving this mail because:
You are the assignee for the bug.
