communication between vlan
-
effectively, pfSense is connected directly to the upstream router via a switch which delivers the DHCP address via ethernet cable.
I could have an address of this router via WIFI but when I do the pping I disconnect from this WIFI and only leave the connection via ethernet.
Here is my ipconfig of the client connected on the LAN. I only have this interface connected:
when I do a traceroute of 8.8.8.8 :
and when I do a traceroute of my other client's IP I get this :
and of course no ping marked in States
-
@Nimizu said in communication between vlan:
and of course no ping marked in States
the icmp states wont be there long.. get a constant ping going
ping ipaddres -t
is windows way to do it..
Now while that ping is running look in your states..
You sure you have firewall running? The only way I could see that working is if firewall is off, but that would disable nat, these clients have internet access while like that, or only if you enable wifi on them? But if you were using pfsense as router only.. It wouldn't be showing you the states for the pings you showed either.
The only other way it could work with firewall off is if your upstream device was natting downstream networks.
-
I don't have a NAT rule to configure and yes my firewall is activated. I tried pinging 192.168.102.102 -t but no apparent change.
For the LAN, internet access was automatic but for the WIFI vlan I had to put rules in place to have internet access
-
Where 192.168.102.1 is the pfSense interface in that VLAN?
If you just ping that directly do you see a state opened for it?
-
@Nimizu well if there are no states being created, there would be no way to block the traffic with a firewall rule.. Because how the firewall blocks the traffic is prevention of a state being created.
So your client on lan or opt can ping 8.8.8.8 - and you see no states with that either?
-
the 192.168.102.1 interface is the gateway for port 2 which corresponds to my LAN.
I tried to ping 8.8.8.8 with the pfsense tool using the LAN interface as the source. But no open state.
All my firewall rules are Pass and not Block or Reject.
-
@Nimizu said in communication between vlan:
I tried to ping 8.8.8.8 with the pfsense tool using the LAN interface as the source. But no open state.
Hmm, you should definitely see a state for that. As long as you are looking whilst the ping is running because the ICMP states expire quickly as johnpoz said.
Try running it from the pfSense command line:
ping -S 192.168.102.1 8.8.8.8Then check for a state in the gui.
-
@stephenw10 said in communication between vlan:
ping -S 192.168.102.1 8.8.8.8
I tried, but again the same result.
I pinged directly into the pfsense shell:
mais je vois toujours uniquement ce résultat meme en regardant en meme temps que le ping :
-
Hmm, are you 100% sure that's the same firewall? There is almost no way to have it not open a state for that ping whilst also opening a state for the monitoring pings. You would have to set a rule to pass pings without opening a state. Which is possible but pretty advanced!
Unless that state view is filtered?
You should see like:
[24.08-DEVELOPMENT][admin@6100.stevew.lan]/root: ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=56 time=25.121 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=5.349 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=5.644 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=5.487 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=6.221 ms[24.08-DEVELOPMENT][admin@6100.stevew.lan]/root: pfctl -vss | grep -A 1 1.1.1.1: ix3 icmp 172.21.16.246:64122 -> 1.1.1.1:8 0:0 age 00:00:58, expires in 00:00:10, 59:59 pkts, 4956:4956 bytes, rule 119, allow-opts -
yes I am indeed on the same firewall.
I tried to do what you just did and I got this result :
-
Ok, good. You should see that in the gui also if it's not filtered.
You should also see states for pings between VLANs with the correct filtering.
If not try that at the command line too.
-
yes indeed on the graphical interface I see this clearly but as I showed you this is what is there on the graphical interface and which corresponds to the result that I sent previously.
I receive dozens of packets every second in this state even though no ping is in progress
-
@Nimizu said in communication between vlan:
I receive dozens of packets every second in this state even though no ping is in progress
Again you are not receiving those, that is the monitoring that pfsense does where it send 1 ping every half second. You must of setup your monitoring to use 8.8.8.8 vs your actual default gateway.. You can clearly see the destination is 8.8.8.8 so its the dpinger service doing its monitoring.
-
Start a ping from some client on one of the internal VLANs to 1.1.1.1.
Then look for the states created in the GUI and at the CLI like you just did.
-
-
@Nimizu so something wrong with the gui not showing the states.. But something odd.. is looks like that output shows ALL for the interface?
Which maybe explains why gui not showing them???
Notice mine shows igb0 and igb1 my lan and wan interfaces.. Not sure why your output shows all vs some specific interface.
-
Because 24.03 switched (back) to interface bound states as default. In 2.7.2 and 23.09 states are floating on 'all' interfaces. So that looks correct.
You should see those states in the GUI if you filter that by
1.1.1.1also.That traffic is passing through the firewall and should be blockable.
-
let's go. I finally see on the GUI.
I now tried to ping a client that is in another vlan and I got this result:
So I tried to make the blocking rules and when I do the following rule this blocks the ping :
thank you very much for your help but I don't understand everything because I just reactivated the rules that I had already made and now it works and before it didn't work.
But the importance and that now it works. THANKS
-
@Nimizu think we went down a deep rabbit whole there on the states not being in the gui.. You were filtering?
Once a state is created the state allows, so if you test something and then try to block it - you have to make sure you either kill that state or wait for it to timeout or close on its own. Before your rule will work.
-
Mmm, I'm not sure what happened there. It seems like either the traffic was bypassing the firewall entirely and now isn't for some reason. Or we were just not looking correctly.
