Bug report
Describe your environment
- Device: Laptop
- OS name and version: Fedora Workstation 44 (
iptables is iptables-nft)
- IVPN app version: v3.15.6
Describe the problem
With the firewall enabled and "Allow LAN traffic when IVPN Firewall is enabled" turned on, IVPN's firewall rules still drop inbound DHCP DISCOVER and broadcast REQUEST packets. These are sourced from 0.0.0.0 (destination 255.255.255.255) - not an RFC1918 address - so they don't match the current LAN exceptions, fall through the IVPN-IN-*-EXP chains, and hit the final drop. As a result, any LAN client that must acquire or rebind a lease while the firewall is up cannot get an address.
I encountered this issue with libvirt/virt-manager VMs, whose DHCP lifecycle is independent of the host's. It occurs on the libvirt default NAT network (virbr0, 192.168.122.0/24, dnsmasq DHCP).
Steps to reproduce:
- Enable the firewall and "Allow LAN traffic...".
- Run a libvirt/virt-manager VM on the default NAT network.
- Make the VM acquire a lease from scratch while connected (either let the host idle until the VM's lease lapses, or in the VM run
nmcli device disconnect <iface> && nmcli device connect <iface>).
Observed Results:
- The VM loses and can't re-obtain an IP address.
- The VM never receives an offer and activation fails (IP configuration could not be reserved). The
DISCOVER is visible on virbr0, but is dropped on the host INPUT path before reaching dnsmasq.
Expected Results:
- With "Allow LAN traffic" enabled, the LAN client can complete DHCP and obtain an address. Acquiring a lease is a prerequisite for the LAN access the setting claims to allow.
Root cause
User/LAN firewall exceptions are rendered as a source match on the inbound chain:
-A IVPN-IN-STAT-USER-EXP -s 192.168.122.0/24 -j ACCEPT
-A IVPN-OUT-STAT-USER-EXP -d 192.168.122.0/24 -j ACCEPT
A DHCP DISCOVER from an unconfigured client has source 0.0.0.0, which is in none of the allowed RFC1918 LAN ranges, so it matches no exception and is dropped. (Adding 255.255.255.255/32 as an exception does not help - inbound matching is on source, and the source is 0.0.0.0, not the broadcast destination.)
Why the issue doesn't/rarely happens on physical hosts
On a physical host, the lease is obtained before the VPN connects, and renewals are unicast to the server with a real RFC1918 source - both permitted by "Allow LAN". Only the from-scratch DISCOVER (and REBINDING broadcast) is affected, which rarely fires for a normal host but routinely fires for a VM guest with an independent lease lifecycle.
Diagnostics steps taken
dnsmasq logged a successful exchange at boot, but nothing during the failure, indicating that the DISCOVER never reaches it.
tcpdump -ni virbr0 'udp port 67 or udp port 68' confirms the DISCOVER reaches the bridge but no offer is produced. (dnsmasq sends offers via an AF_PACKET socket, bypassing the OUTPUT firewall - so if it had received the DISCOVER, the offer would be visible regardless. It isn't.)
I created an nft trace table to follow the DHCP packets through the firewall chain:
sudo nft add table ip dhcptrace
sudo nft add chain ip dhcptrace pre '{ type filter hook prerouting priority -350 ; }'
sudo nft add rule ip dhcptrace pre udp dport 67 meta nftrace set 1
Watching the trace via sudo nft monitor trace until the VM's next DISCOVER (it's auto-retrying every 45s) showed the drop consistently occurring inside IVPN's chains:
... iif "virbr0" ... ip saddr 0.0.0.0 ip daddr 255.255.255.255 udp sport 68 dport 67 ...
... IVPN-IN-ICMP-EXP ...
... verdict drop
(Remember to clean up afterwards via sudo nft delete table ip dhcptrace if you follow these steps.)
Proposed changes
To me, the "Allow LAN traffic when IVPN Firewall is enabled" option doesn't appear to fully work. If a user turns that on it seems reasonable to expect that VMs can actually participate in the LAN, and DHCP is generally how you join a LAN. A switch that allows LAN traffic but blocks the DHCP needed to get a LAN address seems internally inconsistent.
When "Allow LAN traffic" is enabled, can IVPN also be made to permit client-side DHCP regardless of address: accept inbound udp sport 68 dport 67 and the 0.0.0.0 → 255.255.255.255 broadcast/acquisition/rebind traffic (and the corresponding outbound). Presumably other VPN clients do exactly that.
(A similar fix would presumably be required for DHCPv6 (UDP 546/547, ff02::1:2).)
Bug report
Describe your environment
iptablesisiptables-nft)Describe the problem
With the firewall enabled and "Allow LAN traffic when IVPN Firewall is enabled" turned on, IVPN's firewall rules still drop inbound DHCP
DISCOVERand broadcastREQUESTpackets. These are sourced from0.0.0.0(destination255.255.255.255) - not an RFC1918 address - so they don't match the current LAN exceptions, fall through theIVPN-IN-*-EXPchains, and hit the finaldrop. As a result, any LAN client that must acquire or rebind a lease while the firewall is up cannot get an address.I encountered this issue with libvirt/virt-manager VMs, whose DHCP lifecycle is independent of the host's. It occurs on the libvirt default NAT network (
virbr0,192.168.122.0/24, dnsmasq DHCP).Steps to reproduce:
nmcli device disconnect <iface> && nmcli device connect <iface>).Observed Results:
DISCOVERis visible onvirbr0, but is dropped on the host INPUT path before reaching dnsmasq.Expected Results:
Root cause
User/LAN firewall exceptions are rendered as a source match on the inbound chain:
A DHCP DISCOVER from an unconfigured client has source
0.0.0.0, which is in none of the allowed RFC1918 LAN ranges, so it matches no exception and is dropped. (Adding255.255.255.255/32as an exception does not help - inbound matching is on source, and the source is0.0.0.0, not the broadcast destination.)Why the issue doesn't/rarely happens on physical hosts
On a physical host, the lease is obtained before the VPN connects, and renewals are unicast to the server with a real RFC1918 source - both permitted by "Allow LAN". Only the from-scratch DISCOVER (and REBINDING broadcast) is affected, which rarely fires for a normal host but routinely fires for a VM guest with an independent lease lifecycle.
Diagnostics steps taken
dnsmasq logged a successful exchange at boot, but nothing during the failure, indicating that the DISCOVER never reaches it.
tcpdump -ni virbr0 'udp port 67 or udp port 68'confirms the DISCOVER reaches the bridge but no offer is produced. (dnsmasq sends offers via anAF_PACKETsocket, bypassing the OUTPUT firewall - so if it had received the DISCOVER, the offer would be visible regardless. It isn't.)I created an nft trace table to follow the DHCP packets through the firewall chain:
Watching the trace via
sudo nft monitor traceuntil the VM's next DISCOVER (it's auto-retrying every 45s) showed thedropconsistently occurring inside IVPN's chains:(Remember to clean up afterwards via
sudo nft delete table ip dhcptraceif you follow these steps.)Proposed changes
To me, the "Allow LAN traffic when IVPN Firewall is enabled" option doesn't appear to fully work. If a user turns that on it seems reasonable to expect that VMs can actually participate in the LAN, and DHCP is generally how you join a LAN. A switch that allows LAN traffic but blocks the DHCP needed to get a LAN address seems internally inconsistent.
When "Allow LAN traffic" is enabled, can IVPN also be made to permit client-side DHCP regardless of address: accept inbound
udp sport 68 dport 67and the 0.0.0.0 → 255.255.255.255 broadcast/acquisition/rebind traffic (and the corresponding outbound). Presumably other VPN clients do exactly that.(A similar fix would presumably be required for DHCPv6 (UDP 546/547,
ff02::1:2).)