@alek
Not clear, what you try to achieve now or what you're missing.
As you stated above, you want certain host to go out on WAN2 and the others on WAN1.
So assuming WAN1 is your default gateway, add all IPs, which should use WAN2 to the GW2_IPOUT alias and it should do that.

The second rule is applied to all other IPs then. The third one is not needed anymore.

Of course you still need the rule for allowing DNS access to pfSense without any gateway stated.

@nogbadthebad said in WAN vs mvneta0.4090 - SG 1100:

@agreed5101 said in WAN vs mvneta0.4090 - SG 1100:

In my firewall logs i am seeing events on both the WAN interface and mvneta0.4090
48ef4869-9bce-4b50-9d34-363dfca95402-image.png

In this example is the firewall event for mvnet0.4090 originating from my internal network? Are you able to help me understand better the role of the 2 interfaces and what it means for traffic to be blocked on each one?

fbeeea54-16fe-4783-9e22-02947d664186-image.png

I have an SG-1100. For additional context on why I am curious about this, I am trying to get a chromecast to work that is in a separate VLAN than the devices i want to cast from. I have avahi running and firewall rules opened up between the 2 VLANs.

What's connected to the WAN port, a Draytek modem ?

https://cetteup.com/31/how-to-stop-your-draytek-vigor-router-modem-from-broadcasting-its-dsl-status-on-port-4944/

https://www.draytek.com/support/knowledge-base/5365#linux

Thank you, I do indeed have a draytek modem and disabling broadcasting has stopped those events

@jarhead said in WAN vs mvneta0.4090 - SG 1100:

@agreed5101 said in WAN vs mvneta0.4090 - SG 1100:

Are you able to help me understand better the role of the 2 interfaces and what it means for traffic to be blocked on each one?

For the role of each port you need to think of what it actually is.
You have a WAN connected to the internet, then there's a "LAN" port off of that, that is the uplink to the switch and is the virtual port connecting to the virtual switch.
Then you have the physical LAN and OPT ports which are ports on the switch.
So think of a router with a WAN and LAN, with the LAN connected to port 1 of a 3 port switch, Port 2 of that switch is the LAN port and port 3 is the OPT. That's all in the 1100.

Thank you

@johnpoz To me it's the old adage "You don't know what you don't know". I've wondered in the past how DHCP works without any rules but never dove into it and just chalked it up to some sub-process of DORA. Now I'm sure there are a whole host of processes that do things behind the scenes that have exclusions I don't know about. I've just never stopped to consider it. Now that I have, it makes me wonder (and a little paranoid) that there are allow rules I don't know about. Personally I would have considered my lack of knowledge in the area if there were a "Show All" button or something like that for me to understand which rules are built in and which ones are explicitly created by me.

Over the years I've sat through many Cybersecurity courses, seminars, and videos, gone through Net+ and Sec+ (and other) training, and have touched many different vendors routers and I've never seen it brought up. I've worked with 3rd party companies who come in after a breach who need to see the firewall rules but they've never asked to see any hidden rules. We switched from installing Untangle to Pfsense in 2013 during the 2.1 era so we've been using it for over 10 years now. It's realizations like this that make me feel I'm always at the peak of the Dunning-Kruger curve and it's all downhill from here.

@rds25

Ok I found the solution by using "tag" and tagged" to do KILL switch with the rules.

There is an option for "kill switch" in Routing > Gateways > Edit:

51c563e8-3e00-4498-9105-b238731e2bbf-image.png

This is perhaps what you want, I didn't see any "tag" or "tagged" options with the rules.

Either way, happy to help!

@newuser2pfsense I already gave you an example of a locked down vlan..

Customize to your hearts content - rules are evaluated top down, first rule to trigger wins - no other rules are evaluated. It not difficult to come up with a set of rules to be very precise in what they allow or don't allow..

For example your block rules before your allow rule accomplished your goal of not getting those IPs, etc. Could prob just be done cleaner, etc..

This rule pretty useless

useless.jpg

Something on the wlan net would never send any traffic to pfsense to talk to something else on the wlan net - so what exactly could this rule be wanting to allow where pfsense would be involved?

@pirateparley said in No Internet connection rule but still pings in dignosis tab:

inbound is open by default

Seems like your confusing terms.. if traffic is leaving pfsense interface on network X, that is not inbound to X, that is outbound from pfsense.. egress..

If you want to understand direction ingress or egress (inbound or outbound) - then pretend pfsense is a house and your standing in the middle of it... And the interfaces are different doors, the front door, the back door, etc..

"inbound" is not open by default, the default is deny.. Pfsense only checks traffic inbound into pfsense normally. Guy shows up and knocks on your side door (lan) and says hey I want to go to the back yard (connected via the back door)... Do the rules on the side door (lan) say he can do that.. Then he can.. You don't again check traffic as he tries go out the back door into the back yard.

Not unless you created a floating rule and direction was outbound.

Understanding traffic flow is not difficult and quite intuitive when you stop thinking of traffic flow as a device, and look at traffic flow in perspective of the firewall.. The traffic is either inbound into pfsense through the interface... Or its outbound from pfsense into the network

@johnpoz said in I'm sick of neer-do-wells hitting my WAN with TCP:SYN:

If your phone ringer is off, does it really matter if a spammer calls you - you don't answer the phone anyway because the phone doesn't ring.. But you might not like picking up your phone and see missed calls.

My ringer is on as I have an IPSec VPN & SFTP server local 😁

That type of log entry is something you might see if there is a mechanism monitoring the port to see if it's open but not actually attempting to connect as a client. For example if you have something like haproxy setup with a TCP entry for SSH to that system and it is performing a health check.

For example, this does a simple TCP handshake test without sending or receiving data:

Host A:

$ nc -vz x.x.x.x 22 Connection to x.x.x.x 22 port [tcp/ssh] succeeded!

Host B:

Jan 23 11:39:30 target sshd[17392]: error: kex_exchange_identification: Connection closed by remote host Jan 23 11:39:30 target sshd[17392]: Connection closed by x.x.x.y port 48544

It's also possible you have something inside doing that but it's hitting NAT reflection on the firewall so it appears to come from the firewall, but the real source is elsewhere inside your network.

Lastly, you might have configured outbound NAT on that interface masking the source of the traffic.

Colleagues, good afternoon. After a long time of trying, I managed to get the vlan to work with the pfsense in bridge mode. the WAN and LAN work perfectly, however, when creating another bridge with the WAN interface and the physical LAN without VLAN, the previously created VLAN stops working, but when I remove the WAN interface from the bridge it works again. What could be causing the problem?

@johnpoz
OK - that makes things clearer. The onus is on me to make all the settings consistent with each other.

Thanks!

@cobain what are you rules.. please post up what you currently have set for lan and opt1

If they are really any any rules, and you don't have any floating rules that would block. And your not policy routing traffic out some gateway, like your wan or some vpn then issue with clients not being able to talk is either they are not actually using pfsense as their gateway. The clients have the wrong mask on them, seen this quite a bit actually.. Where users set static IP on a client and use say a /16 mask.. So it thinks the other network/vlan is just local and never sends traffic to its gateway to get to the other network, or to answer traffic.

Client firewalls is always big overlook by users..

Wrong protocols for example - your rule there were lan was source to opt1 on opt1 interface was only tcp/udp - so no pinging even if the rule was correct wouldn't work..

you can always sniff (packet capture on pfsense) to validate traffic is actually getting sent to pfsense on your lan for example, and then sniff on your opt1 interface to see that traffic is being sent on to your destination IP..

@the-stranger I don't recall hearing that before. You can turn it off and try. Bogons are unassigned IP ranges.

@bob-dig Thanks going to go through that today and update you

@viragomann Thx for your help.

I have to think about which would be the best way now. As it's a testing setup I have no problem starting everything over again.

@steveits This fixed the issue for me.
Thank you!
328e3f2e-11cc-496f-9bc7-47a0c2966c07-image.png

@viragomann
Thanks so much for the help...this was exactly what I was looking for (but didn't know existed 😃 )