unable to connect vlan to vlan?
-
@nick-loenders again rules are evaluated top down..
rule to allow to 230
rule to block to rfc1918 alias
rule to anySo now 220 can talk to 230
but not any of your other vlans because they are all in the rfc1918 space
but if wants to talk to say 8.8.8.8 or 9.9.9.9 etc.. that is allowed by the any rule at the end.edit: here is a picture example
So I allow some required stuff, like ping pfsense to validate connectivity. Use dns and ntp on pfsense test address.
Then block all access to any other pfsense IPs on any interface, say the wan IP that is public and could change to prevent access to say the pfsense gui.
I then allow access to the guest network. But block all other access to any other rfc1918 address space, my other vlans. And then the last rule allows access to the internet (any)
-
@johnpoz
Ok so I got now:
But I cannot ping internet, nor surf.
Firewall even blocks on DNS:
Weird, nah?
-
@nick-loenders said in unable to connect vlan to vlan?:
Weird, nah?
Now your only allowing tcp, most dns is always udp.. Your dns rules should be for both tcp/udp since sometime tcp can be used.
Curious why you put in IP vs just vlan220 address alias? Is 20.253 not pfsense actual IP? Is it a vip or something?
If dns is not working you have a hard time resolving, and surfing anything. Can you say ping 8.8.8.8 ?
-
@johnpoz
Hi,
Those my DNS rules look okay? This is on the LAN interface.
Can I use the same rules on my other interfaces also?I have seen others using almost the same rules, but they use LAN Net as SOURCE.
-
@moonknight source should really always be the net the interface is connected to.. Only time it shouldn't be is if your using it as a transit network. But lan makes for a horrible transit because there should be no hosts on a transit network or you run into asymmetrical problems.
That first rule is attempting to redirect anything to loopback, which is fine - but then kind of makes the second rule pretty pointless. Is that tied to a port forward rule?
I would put the lan address rule above the rule from the port forward, just for easier reading
-
@johnpoz
Hi again, and thanks for your answer :)I was following docs at netgate.
1 rule:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html2 and 3 rule:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-block-external.html2nd rule is not port forward. The 1st rule is NAT rule.
So I can remove 2nd rule then :)1st rule NAT
-
@moonknight said in unable to connect vlan to vlan?:
2nd rule is not port forward. The 1st rule is NAT rule.
huh? Not really its a "port forward" ;) look what section of nat rules you put it in hehehe
If your 1st rule there allows the port forward, so it would depend on the destination of your port forward if that 2nd rule is needed. Since you have it ! lan address, then you need it - but I would just put it above is all.. If you remove it you wouldn't be able to actual talk directly to the lan address for dns ;)
-
@johnpoz
Damn, you got me, hehe :)
Of course, it is a port forward.Something like this?
Should I also put "LAN Net" in the source? In all of them?
-
@moonknight its cleaner to have lan net there, makes it easy to know what interface your on, etc.
I mean when would there ever be anything other than lan net coming into that interface as source ;)
-
@johnpoz
I did it like this and that worked :)
The 10.233 is the WAN ip of my home setup modem..... Therefore it did not work when blocking the PrivateNetwork :)
-
@nick-loenders You mean you couldn't access its gui? Or the internet, since it would have nothing to do with internet access.
And your rules block it anyway - Remember, order top down. So trying to get to 192.168.10.233 is blocked by the private nets rule before it even gets to your allow rule.
What I don't get is why none of your rules are even showing being used... They are all 0/0 for states.. That means pfsense has not seen any traffic that matches any of those rules.
-
Well, at home, where it was as setup the internetmodem/router gives me 192.168.10.0/24 addresses. So the WAN ip of the pfsense was 10.233, but as 192.168.10 is blocked by the rule, I could not get passed the modem/router.
At the office now, I have:
And this works as it should.
-
@nick-loenders said in unable to connect vlan to vlan?:
I could not get passed the modem/router.
Again that rule you added wouldn't of worked, because it was below the block rfc1918 rule, unless you didn't have 192.168 listed in the alias? But if you didn't then you wouldn't of need a special rule to allow since your any at the bottom would of allowed.
Also even if you blocked access from your lan to the modem/router IP - that wouldn't of had anything to do with internet access. Since your clients behind pfsense would never be going to that IP other than trying to access its web gui.
-
@johnpoz
So this should be the correct order then?
-
Yeah those would work for allowing devices on 208 net to talk to those 10.2 Ips, as long as those are not IPs of pfsense since your blocking "this firewall" first.
If those are name servers - you prob want those rules to be udp/tcp.. In some instances dns can and does use tcp..
-
@johnpoz
The 10.2.50.252 is the VIP of the pfsense, the 50.253 and 10.2.8.253 are the DNS servers the pfsense uses when I do a ipconfig on the laptop.I changed a little:
But this 208 is used by an SSID on the wifi. If I connect to that SSID , I cannot access the internet?
-
Guess my order was wrong.
did :
And now it seems to be better for the internet. But now I CAN access the firewall gui and that I don't want? :(
-
@nick-loenders so what are those IPs 10.2.x are those pfsense IPs? Either way if you want to block access to gui of pfsense on its IPs
Create a rule at top that blocks access to the webgui ports (say 80 and 443) to "this firwall"
-
I do my best :) But it won't block.
Off course the LAN net is the 10.2.50.0/24 as well, problem in there ?
Private_Networks is:
VLAN 208 has ip's 10.2.8.0/24
-
@nick-loenders you need to check states.
If something is allowed, and you connected to it. A state would be created allowing that traffic. If you then put in a block to that thing. Until the state goes away it would still be allowed, states are evaluated before rules.
So you need to either wait til the state expires, or you kill it via the state table in diagnostic menu.
Also when troubleshooting firewall rules, make sure you don't have something in the floating tab that would allow it.
It goes states
floating rules
interface rulesSo even if you create a block in the interface, if you have some quick rule set in floating that allows it, it would be allowed no matter what rules you put on the actual interface.
edit: BTW 172.16 is a /12 mask not a /16... The 172 space is 172.16-31
