Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Demusman

#1
General Discussion / Re: Inter Vlan Routing
June 08, 2023, 09:48:54 PM
Quote from: routeswitched on June 08, 2023, 06:50:16 PM
Still no luck, I can ping the gateways but not the host. Firewall rules wide open on LAN and the .64 network. They are both on separate interfaces now.

LAN ix0
.64 ix1

Are you sure it's not just a software firewall on the host?
#2
Show the switch config on the ports needed.
You should have the port going to the router as a trunk with vlan 88 tagged on it.
Then whichever port you're using for that vlan should be untagged with vlan 88.
#3
You don't 'need' 2 adapters.
If you have a vlan capable switch you can use a vlan for either WAN or LAN. Or both.
#4
The first message tells you how to log in. Use "installer" as username.

You're not gonna have much luck with that USB adapter though. You really should get rid of it.
#5
Quote from: Greelan on April 16, 2023, 02:04:57 AM
Quote from: Demusman on April 16, 2023, 01:18:31 AM
By all means, go ahead and point out what is inaccurate in either of the first two posts.
Like in the past, you have missed my point - maybe it's deliberate?

Didn't miss your point at all, but maybe it's aimed in the wrong direction?

When someone points out a problem, especially one that is constantly brought up, and then they get a response of "I'll bet you two are wonderful to work with.  ::)" and "This thread is embarrassing.", Who's being the dick?
There was nothing in the original posts that was out of line or meant with malice. And there was no need to reply like he or she did about it.
As for my response, yes, I give what I get.

And I'll reiterate, it was 100% accurate. Please point out the inaccurate points.
#6
Quote from: Greelan on April 16, 2023, 12:26:11 AM
No, BondiBlueBalls is "100 accurate". By all means make suggestions for improvement or highlight problems (preferably with ideas for solutions) - just don't be a dick about it.

By all means, go ahead and point out what is inaccurate in either of the first two posts.
#7
Quote from: BondiBlueBalls on April 14, 2023, 04:06:43 PM
I'll bet you two are wonderful to work with.  ::)

Why is it so difficult to be polite and kind to the people who build the free and open software we use? Don't like something and think you have a good idea? Reign in your entitlement and provide constructive feedback. If you can't manage that, make the changes yourself and create a PR.

This thread is embarrassing.

Aww, sorry to hurt your precious feelings.
If you weren't so sensitive you'd be able to admit that this thread is 100 accurate.
#8
You forgot to mention assigning peers.
Why do we have to go back to the tunnel and assign a peer there???
You're not assigning a tunnel to a peer, you assign a peer to a tunnel.
Out the assignment on the peer "screen" and select the tunnel you're assigning it to.
But that makes too much sense for opnsense.
I've said it for a long time now, the interface is a mess.
#9
You can't block anything generated by the firewall itself if that's what you're trying to do.
All rules are evaluated on the IN of the interfaces, the firewall would never generate traffic INTO an interface.

If you want to block traffic from the internet, you put the rules on the WAN.
Again, IN to an interface is traffic generated from the directly connected network of that interface. So the WAN would be directly connected to the internet by way of your WAN Network alias.

Can I ask, why would you want to block traffic from the firewall itself?? What exactly is being generated there?
#10
Quote from: nzkiwi68 on April 10, 2023, 04:53:11 AM
When writing firewall rules, you need to think of packets from the firewalls point of view.

That's very important.

Firewall rules, in general, are set again an interface, and the direction is normally IN. That's because, from the firewall's point of view, a packet going out to internet from a LAN connected device, is received (hence IN) on the firewall's LAN interface. From there the packet does through the firewall rules, NAT and then leaves (out) on the WAN interface. With stateful firewalls (and OPNsense is most certainly a stateful firewall) you only write a firewall rule for the FIRST packet.

See the OPNsense documentation:
https://docs.opnsense.org/manual/firewall.html

Short answer, don't use OUT as a direction. It will only ever apply to floating rules and floating rules should not be used unless absolutely neccessary.

Long, in PF rules are applied on the interface as traffic enters that interface. First rule that matches is applied and no other rules are evaluated, so order matters.
The best analogy I found is using a house.
Your house has many doors in it, these are the interfaces. If you want to stop a packet from exiting your back door, you don't let it in the front door and then tell it the backdoor is off limits. You block it from entering the front door. Thereby blocking all other doors.
So if a packet is allowed in the front door, it then has access to any of the other doors you allowed it from the front door.
It makes sense when you wrap your head around it.

You also need to understand that IN and OUT refer to the same interface.
Take the LAN interface. IN is a packet entering the interface FROM the directly connected network. (LAN)
OUT is a packet leaving the interface TO the directly connected network. (LAN)
A lot of people think LAN OUT is to the WAN or other interfaces, it's not.

So never use OUT as a direction on an interface rule. It really shouldn't even be an option except on Floating rules.
Use direction IN and set the rules to what that packet can access.
#11
Quote from: Phiolin on April 03, 2023, 08:00:19 AM
A bit of a strange issue here that I fail to understand.

Client is a MacBook which I mainly use for all kinds of admin stuff.
Client is connected via a switch port that has untagged/native VLAN 10 and tagged VLAN 99 configured.


How are you testing the tagged vlan?
You would have to set the nic in the mac to tag vlan 99 on it.
An untagged nic can't access a tagged vlan.
#12
General Discussion / Re: VLAN Config
March 28, 2023, 09:27:51 PM
You can't use vlan1. Change it to anything else. vlan1 is kinda "special" and is the default vlan of just about every switch ever made.

Again, you can't use the same subnet across vlans. Change it to anything else. Convention will say to use the same tag as subnet, ie 192.168.10.0/24 will be vlan 10, 10.10.20.0/24 will be vlan 20 etc, but that's personal preference.

#13
General Discussion / Re: VLAN Config
March 28, 2023, 08:22:13 PM
You can't use the same subnet on multiple vlans.
Vlan01 is an internal naming convention for opnsense, what tag did you actually use?
If you are using a physical interface on the router, you aren't using vlans. Is OPT1 physical?
You only tag a vlan on a port if the device you're connecting it to is also tagged with that vlan.
You aren't very clear with the details so hard to say but if OPT1 is physical, don't tag the switchport it connects to.
Why are you using .2 as gateway? and for that matter .4 for the other gateway.
Set the lan to 192.168.1.1 and the second subnet to something else like 192.168.2.1.
#14
Keep in mind those are 6 router ports, not switch ports.
You say you want low latency, then you don't want to use those ports as a bridge.
Use a switch for switching.
#15
Get Opnsense running.
Connect the LAN interface to a switchport on the old router.
You can now use the other switchports as needed.

On the old router you have to disable the dhcp server and assign it an IP in the subnet of the opnsense LAN so you can still access it's GUI.
You don't use the WAN port on the old router.