Bug #16296
closed
NAT64 traffic originating on OpenVPN interfaces not routing
Added by Bert Smith 3 months ago.
Updated 17 days ago.
Affected Architecture:
amd64
Description
I have an OpenVPN interface active and then assigned to an interface under interfaces/assignments.
There is then a rule added to allow all traffic from the VPN subnet destined for the NAT64 prefix 64:ff9b::, using NAT64 and translating to the WAN address.
A tcpdump shows the traffic being translated and sent out of the WAN interface, and the remote host responding with a SYN/ACK, but it seems the firewall is unable to forward the traffic back from the WAN interface to the internal NAT64 host.
Attempting to use a portion of my GUA space instead of the 64:ff9b::/96 prefix has identical results.
A separate NAT64 rule applied to WAN which sets aside a portion of my GUA space as a NAT64 prefix is working correctly.
Note: identical rules applied to a standard non-OpenVPN interface are working correctly.
- Affected Version changed from 2.9.0 to 2.8.0
Is the assigned interface for an OpenVPN server, or OpenVPN Client configuration? It would also help to see the relevant rules from pfctl -sr.
Assigned interface is an OpenVPN server.
Rule for the vpn interface:
pass in quick on ovpns4 reply-to (ovpns4 2a01:4f8:141:c0a::2) inet6 from <OPT9__NETWORK> to 64:ff9b::/96 flags S/SA keep state (if-bound) label "USER_RULE: Accept outbound NAT64 traffic" label "id:1751444554" ridentifier 1751444554 af-to inet from (vtnet0)
working rules on other interfaces show up as:
pass in quick on vtnet3 inet6 from <OPT2__NETWORK> to 64:ff9b::/96 flags S/SA keep state (if-bound) label "USER_RULE: NAT64" label "id:1749339328" ridentifier 1749339328 af-to inet from (vtnet0)
pass in quick on vtnet5 inet6 from <OPT4__NETWORK> to 64:ff9b::/96 flags S/SA keep state (if-bound) label "USER_RULE: NAT64" label "id:1749339262" ridentifier 1749339262 af-to inet from (vtnet0)
i'm not sure where the reply-to bit is coming from but that seems to be the key difference, even duplicating the rule from OPT2 and changing only the interface also seems to add the reply-to bit.
It's likely there's a configuration issue. Please open a thread on the forum for further discussion and troubleshooting.
- Subject changed from NAT64 traffic originating on OpenVPN interfaces not routing. to NAT64 traffic originating on OpenVPN interfaces creates a state for the wrong interface
- Status changed from New to Not a Bug
The reply-to tag is indeed the culprit. That tag gets added because the OpenVPN Server interface has been assigned - normally this is only done for the OpenVPN Client and the OpenVPN Server rules are created in the OpenVPN firewall rules tab. If you must have the interface assigned, simply disable the reply-to tag in the rule's advanced options.
Issue for the reply-to tag: #16429. Even with that fixed, there's still the issue of #16351 as well. I'm closing this redmine in favor of the other two.
- Subject changed from NAT64 traffic originating on OpenVPN interfaces creates a state for the wrong interface to NAT64 traffic originating on OpenVPN interfaces not routing
- Status changed from Not a Bug to Closed
Also available in: Atom
PDF
Updated by 
Updated by