ICMP to VLAN's GW
-
Hello,
I noticed that ICMP-IPV4-messages form a computer on one of my vlan's towards the VLAN's gateway are blocked by default.
Which seems strange to me since the destination is an address of the vlan itself.
I also wonder what the goal of the blocked messages is, what I could not find in the log since the message log does not log the involved ICMP-subtype (I did all some ICMP-rules per subtype trying to understand what happens).
Note that I am running 2.7 CE.
Is there someone who can explain why the ICMP is not passed to the GW and what is probably heppening?
-
@louis2 the current stable version of CE is 2.6.0 .
2.7 is in operational for testing phase not recommended in live production environment.Thanks
-
@louis2 well what rule(s) did you put on the vlan. By default when you create a new interface be it native or vlan there are no rules so everything would be blocked.
Dhcp is allowed when you enable it via hidden rules that are auto created when you enable dhcp - but everything else would be blocked, unlike when you first setup and the lan defaults to an any any rule.
-
John, the reason that I am surprised is that it traffic local within the vlan, not traffic to another address range beyond the vlan.
It is traffic like 192.168.2.xyz to 192.168.2.1 where 192.168.2.x is the vlan range and 192.168.2.1 is the VLAN gateway.
And to me it looks strange that a local device is not allowed to send ICMP-messages to its local gateway.
Since I did create a couple of ICMP related rules, each one related to a few ICMP-types, I now now that the blocked ICMP is probably out of the range:
- echo replay, echo request, information replay, information request
The bottom line is the question if rules should yes/no also block access to the local vlan related gateway.
-
@louis2 said in ICMP to VLAN's GW:
f rules should yes/no also block access to the local vlan related gateway.
Again - no rules are are created, you would not be able to ping pfsense IP on that vlan unless you allow for it.
Pfsense has nothing to do with devices on the same network/vlan talking to each other - but no you would not be able to ping pfsense IP on that vlan unless you allow for it.
This would be traffic into pfsense from that network. So by default deny, unless you create a rule to allow it.
I agree with you devices should be able to ping their own gateway - so create that rule and you will be able to. But new interfaces when created have no rules on them, so by default deny.
Post up your rule(s) you have created on this vlan and we can figure out why ping is not working to the pfsense ip of that vlan.
-
OK, conclusion is that the VLAN-GW is not part of the (v)lan it self and that the FW- functionality is between the vlan and its gateway
(and not between the GW and the rest of ^the (local) world^.) -
@louis2 when a host A wants to talk to host B on the same network the "gateway" to get off that network is not evolved in the conversation at all. Unless its host A or B.
A device on a network wanting to talk to another device on the network arps for mac of the IP. If he gets an answer he sends his traffic to that mac.
Pfsense is not involved in that conversation, has no control over that conversation is not aware of that conversation.. Other then it would of seen the arp, but the arp was not asking for its IP so it wouldn't respond.
Pfsense can only control what traffic is sent to it or through it. By default its firewall rules on a new interface are deny. So trying to even just ping its IP would be denied unless you allowed for it rules you created.
-
OK, the situation is clear. Since any system on the vlan should be capable to ping its own GW, I will add three IPV4-rules for e.g. my guest vlan:
- allow ICMP to local GW
- block ICMP to the rest of my local network
- allow ICMP to the rest of the world
IPV6, which behaves different, probably something similar
-
@louis2 IPv6 would work the same way sure. Do you have ipv6?
-
Yep, native allready for an long time
-
Note that my confusion is partly due to some inconsistency. As example:
- you do not have to add a rule for dhcp, however
- you have to open one to allow a ping
Also note that e.g. for my pclan I allow every ping, where I do not allow pings towards my local network from e.g. my guest lan
-
@louis2 said in ICMP to VLAN's GW:
you do not have to add a rule for dhcp, however
This is because users would most likely be confused and more than likely mess it up trying to create rules for dhcp ;)
The adding of hidden rules for dhcp has been around since beginning of pfsense when you enable dhcp on an interface.
Its kind of given if you enable dhcp on an interface you want clients to get dhcp from pfsense. But allowing for xyz traffic might not be the case.
-
Doesn't bother me, but it could be more clear to new users of pfSense, if the DHCP and other hidden auto-generated rules were visible and un-editable in the rules list...
Just like RFC1918 & bogon network block and Anti-Lockout rules, that are placed by settings selections and are also visible in the rules list.But that just my 2 cents... :)
-
@mvikman said in ICMP to VLAN's GW:
if the DHCP and other hidden auto-generated rules were visible and un-editable in the rules list
I hear ya - and yeah that would be a nice feature, say a toggle to show hidden rules maybe.
You could put that in as a feature request on redmine..
edit: guess there has been one for a really long time
https://redmine.pfsense.org/issues/4828But you can always view the full rules list.
https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html#viewing-the-pf-ruleset
example - not full list, snipped some of the interfaces but you get the idea
# allow access to DHCP server on LAN pass in quick on $LAN proto udp from any port = 68 to 255.255.255.255 port = 67 ridentifier 1000002541 label "allow access to DHCP server" pass in quick on $LAN proto udp from any port = 68 to 192.168.9.253 port = 67 ridentifier 1000002542 label "allow access to DHCP server" pass out quick on $LAN proto udp from 192.168.9.253 port = 67 to any port = 68 ridentifier 1000002543 label "allow access to DHCP server" antispoof for $WLAN ridentifier 1000003570 # allow access to DHCP server on WLAN pass in quick on $WLAN proto udp from any port = 68 to 255.255.255.255 port = 67 ridentifier 1000003591 label "allow access to DHCP server" pass in quick on $WLAN proto udp from any port = 68 to 192.168.2.253 port = 67 ridentifier 1000003592 label "allow access to DHCP server" pass out quick on $WLAN proto udp from 192.168.2.253 port = 67 to any port = 68 ridentifier 1000003593 label "allow access to DHCP server" antispoof for $TEST ridentifier 1000004620 antispoof for $NS1VPN ridentifier 1000005670 antispoof for $W_PSK ridentifier 1000006720 # allow access to DHCP server on W_PSK pass in quick on $W_PSK proto udp from any port = 68 to 255.255.255.255 port = 67 ridentifier 1000006741 label "allow access to DHCP server" pass in quick on $W_PSK proto udp from any port = 68 to 192.168.4.253 port = 67 ridentifier 1000006742 label "allow access to DHCP server" pass out quick on $W_PSK proto udp from 192.168.4.253 port = 67 to any port = 68 ridentifier 1000006743 label "allow access to DHCP server" antispoof for $W_GUEST ridentifier 1000007770 # allow access to DHCP server on W_GUEST pass in quick on $W_GUEST proto udp from any port = 68 to 255.255.255.255 port = 67 ridentifier 1000007791 label "allow access to DHCP server" pass in quick on $W_GUEST proto udp from any port = 68 to 192.168.6.253 port = 67 ridentifier 1000007792 label "allow access to DHCP server" pass out quick on $W_GUEST proto udp from 192.168.6.253 port = 67 to any port = 68 ridentifier 1000007793 label "allow access to DHCP server" antispoof for $W_ROKU ridentifier 1000008820
