Regarding flushing/clearing states manually - I guess the goal of introducing '(intf)' was to make manual clearing unnecessary, hence, as a user, I expect that using '(intf)' would do automatic clearing as well. Otherwise, I don't see much benefit to have (). Also, to be honest, I think that introducing '()' into syntax was excessive. May be it would be better to change behavior only, without complexing syntax. Are there still benefits of current behavior without '()' vs one with '()'?
Regarding the issue - I didn't experienced it yet, I am just planning to use OpenBSD as my home Internet gateway. Currently I'm performing PoC stage and analyze what could be in real life. Shown behavior could happen in presence of long-lived NAT sessions, once external IP address has been changed. Thank you. > 4 янв. 2024 г., в 10:35, Alexandr Nedvedicky <sas...@fastmail.net> написал(а): > > Hello, > > On Thu, Jan 04, 2024 at 01:01:30AM +0300, Alexander Okonnikov wrote: >> Hi Alexandr, >> >> The fact that new IP address to be used for new sessions makes sense. >> Though, such behavior could pose problems like follow: >> >> 00:48:30.266195 172.16.0.2 > 172.16.1.3: icmp: echo request >> 00:48:30.266239 arp who-has 172.16.0.2 tell 172.16.0.3 >> 00:48:31.266169 172.16.0.2 > 172.16.1.3: icmp: echo request >> 00:48:31.266239 arp who-has 172.16.0.2 tell 172.16.0.3 >> 00:48:32.266224 172.16.0.2 > 172.16.1.3: icmp: echo request >> 00:48:32.266292 arp who-has 172.16.0.2 tell 172.16.0.3 >> 00:48:33.266300 172.16.0.2 > 172.16.1.3: icmp: echo request >> 00:48:33.266368 arp who-has 172.16.0.2 tell 172.16.0.3 >> 00:48:34.266192 172.16.0.2 > 172.16.1.3: icmp: echo request >> 00:48:34.266244 arp who-has 172.16.0.2 tell 172.16.0.3 >> 00:48:35.266322 172.16.0.2 > 172.16.1.3: icmp: echo request >> >> Here we see, that requests are still NAT'ed using old address (172.16.0.2), >> while another address is assigned on the corresponding interface. At some >> time ARP entry for 172.16.0.2 on neighboring node has been expired, and that >> node is trying to refresh/discover MAC for 172.16.0.2. As far as the >> interface doesn't own 172.16.0.2 anymore, it doesn't respond to such ARP >> requests. As a result we obtain service disruption. >> >> Why not to invalidate existing NAT sessions upon deleting/replacing address? > > the simplest (but brutal) workaround is to flush state > table whenever IP address changes: > pfctl -Fs > command above removes all states from table. better way is > to use 'pfctl -k ...' and kill (remove) only desired states > created by NAT rule before address got changed. > > how did you discovered that issue? like is it a part of > some real world situation you experienced? > > thanks and > a regards > sashan
