How to route promiscuous traffic ?
-
Hi,
In my setup, I have a bridged (but in fact, not a "true" bridge) modem, giving its WAN IP to pfSense through DHCP on igb0, a first LAN subnet assigned to igb1, and a vlan subnet on igb1. The vlan interface's ip is 192.168.30.254.
On this subnet, a device (192.168.30.1) is also trying to connect to the modem directly through a private dedicated subnet (192.168.27.0/24) - that's why it is not a true bridge - to get its config for different services. It's Ip in this "private" subnet is 192.168.27.17, and it's trying to contact the modem on 192.168.27.14. But as it is considered by the interface to be promiscuous traffic, all packets are dropped.
Is there any way to route the traffic from 192.168.27.17 to Wan in order to have an established connection between this device and the modem ?
Thank you for your help
-
@potjoe said in How to route promiscuous traffic ?:
But as it is considered by the interface to be promiscuous traffic, all packets are dropped.
The modem interface?
The problem with modem access is usually that the modem doesn't have a route back to the source so never replies. You need to NAT that traffic to the pfSense interface IP in 192.168.27.0/24 subnet so the modem can reply.
Switch outbound NAT mode to hybrid and add a rule.https://docs.netgate.com/pfsense/en/latest/recipes/modem-access.html
Steve
-
@stephenw10 Not the modem, on the VLAN interface on the LAN side. Sorry if I was not clear. The thing is there is no pfsense interface IP in 192.168.27.0/24 subnet. I have a WAN (igb0) interface with a public IP (not RFC 1918), a LAN (igb1) interface in 192.168.10.0/24 subnet, a VLAN interface (parent : igb1, same as LAN) in 192.168.30.0/24 subnet.
The device is connected on the VLAN interface and gets an IP in 192.168.30.0/24 with DHCP. But actually, it has a second IP address in an undefined range, in the in 192.168.27.0/24 subnet. Looking at the VLAN interface logs, pfsense obviously rejects traffic coming from in 192.168.27.17, since it expects traffic from the 192.168.30.0/24 subnet. This is why I was talking about promiscuous traffic, because the VLAN interface receives traffic from 192.168.30.0/24 and this other 192.168.27.0/24 subnet.
I tried to create an outbound rule to route 192.168.27.0/24 subnet's traffic to the WAN, but thinking about it 1) it will perform a NAT, which I don't need in this partcular case (the modem must see the traffic from an IP in the 192.168.27.0/24 subnet 2) the traffic is still rejected by the VLAN interface, because it expects traffic from 192.168.30.0/24.
To sum up, is there a way to route this promiscuous traffic from my VLAN interface, on the LAN side, to the modem on the WAN side, without NAT ?
-
pfSense will still route that traffic if you have a firewall rule to allow it on the VLAN interface.
The problem is that replies won't get routed back to it because pfSense has no idea where the 192.168.27.X subnet is.
Add an IPAlias VIP on the VLAN in the 192.168.27.0/24 subnet.The modem on the WAN may still have no way to reply to it without outbound NAT though.
Steve
-
@stephenw10 Thanks for your answer. First things first,
@stephenw10 said in How to route promiscuous traffic ?:
pfSense will still route that traffic if you have a firewall rule to allow it on the VLAN interface.
Before handling the reply from the modem, I'm still having issue at the VLAN interface level. Despite a rule to allow traffic coming from the 192.168.27.0/24 subnet, connections are still blocked by the default deny rule. Even if there is no reply, I should not see this traffic blocked, right ?
VLAN Rules
Firewall logs
VLAN Interface config
-
The traffic you're seeing blocked there is all flagged TCP RESET. It's blocked because pfSense has either not seen the initial traffic opening the TCP connection or that state has already timed out.
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#troubleshooting-blocked-log-entries-for-legitimate-connection-packetsAdditionally here though the source and destination appear to be in the same subnet. Unless pfSense has 192.168.27.14 I would not expect to see that traffic going through the firewall at all.
Steve
-
@stephenw10 Sorry for the absence I've been away for some days. Indeed, in the capture we see TCP traffic with RESET flags, there are also Acknowledgement flags that are not shown here, from the same source and destination.
Source and destination are in the same subnet : the "device" is the source here, on the LAN side, and expects to find the destination "modem" on 192.168.27.0/24 subnet. But, the modem is on the WAN side. This is limitation from my internet provider which provides both the modem and this device. Both uses this subnet to manage configurations for different services. I know from its documentation that this behaviour is implemented even if the modem is in bridge mode : this is why I it called "not a true bridge". The modem is still using this private subnet, specifically to communicate with this device, even in bridge mode although you're expected to run a firewall/router in between.
I am aware that
@stephenw10 said in How to route promiscuous traffic ?:
Unless pfSense has 192.168.27.14 I would not expect to see that traffic going through
because you should not see traffic on private subnets go through the firewall.
But in this case, the limitation from my provider makes me wonder if I can route this traffic anyway, without nat, from the device to the modem. -
@potjoe said in How to route promiscuous traffic ?:
because you should not see traffic on private subnets go through the firewall.
Nope. Because you cannot have the same subnet on two interfaces, it breaks routing, so traffic there should all be on o9nbe interface and the two devices talking to each either directly.
But here you are in fact trying to workaround some ISP requirement where you have two devices in the same subnet on different interfaces.
I still don't expect to see it on the firewall because they should just ARP for each other and fail. I'm not sure how that TCP session can ever establish.The only way I can see this working is be bridging and that would probably break numerous other things.
What exactly is this device on the LAN? Does it have to be on the LAN?
Steve
