pfSense Support Subscription

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.


Messages - tlum

Pages: [1] 2 3 4 5
1
Your question was simple enough, let me quote:

Quote
How would you configure an interface for the native/untagged VLAN in a trunk?
...
Also, some switches can tag untagged trunk traffic ... but I am interested in how you would do it with pfSense

We already told you in quite simple and straightforward english that pfSense won't do that at all because it's a router/firewall operating system based on FreeBSD, not a switch. FreeBSD has no facilities for the kind of VLAN ID manipulation you keep wishing it had, zero, nada, zilch.

Yes, my question was simple enough, but apparently the words I used to ask it were not, so let me clarify:

How would you configure an interface for the native/untagged VLAN in a trunk? I can think of ways to mitigate the question elsewhere in the infrastructure, but assuming I can't deploy mitigation elsewhere, how would you configure an interface for the native/untagged VLAN in a trunk?


Also to clarify something if it wasn't clear enough:

Quote
Isn't em0 everything? I'm under the impression that em0_vlan100 is a subset of em0, so em0 "would include", but is not explicitly constrained to, untagged?

Em0 is the untagged traffic and only the untagged traffic, everything that is tagged on the wire connected to em0 has to go trough the configured VLAN interfaces.
Far from a clarification, if correct, this would actually answer my question and contradict what you just said about it not being possable, but, Derelict, Myself, and tcpdump are just going to have to agree to disagree with you here.

2
LAN assigned to em0 will get the untagged traffic
OPT1 assigned to em0_vlan100 will get the tagged traffic (tag 100).

From that point there is no VLAN inside pfSense. The tag has been stripped and the traffic is ROUTED. If it happens to be routed out the LAYER THREE INTERFACE assigned to em0_vlan200 it will be tagged with VLAN 200 there. If it happens to be routed out the LAYER THREE INTERFACE assigned to em1 it will be sent untagged there.

Everything else is your switch's job.

In my case em0... actually bond0 because it a VPN trunk over a LACP trunk... is:

WAN1 (public subnet)
WAN2 (public subnet)
DMZ1 (private subnet)
DMZ2  (private subnet)
LAN1  (private subnet)
LAN2  (private subnet)
VPN  (private subnet)
Wireless  (private subnet)
[Native  (private subnet(s))]

You can't (or at least shouldn't) use that interface for ingress. You take out 802.1q filtering and your greatly expand the attack surface by sending a lot more further up the stack.

What I'm hearing is that pfSense can't create a default interface dedicated exclusively to untagged traffic. The only way to do it is place a switch in front that default tags all native trunk traffic upon ingress. I'll have to dig and see if the Cisco 2960's can do it now... I just remember customers griping about how the flag was enabled but it wasn't working, and Cisco replying that the flag was generic to IOS but had no effect because the 2960's don't support it... but that may have changed since then.

3
If you assign an interface LAN to em0 and an interface OPT1 to em0_vlan100, em0 will be untagged to/from the switch. em0_vlan100 will be tagged with VLAN 100.

If you packet capture on em0 you will see tagged and untagged traffic but in the normal course of operation, LAN will only see the untagged traffic, OPT1 will only see the tagged traffic.

When designing networks, I avoid mixing tagged and untagged traffic on a link wherever possible. Exceptions are made where manufacturers require it (cough Ubiquiti cough). On pfSense I tag everything and leave the untagged interface (like em0) unassigned.

em0 is just not 802.1q aware, and there are some serious security ramifications here if you ignore tags on a trunk. That might be useful for egress, were you actually trying to generate untagged traffic for some reason, but my use case is the reverse. I have untagged ingress that needs to feed a specific ruleset. More often than not that native traffic is going to be routed into a tagged VLAN because of the destination subnet. In the real world you don't have the luxury of the purists view, you have to deal with the diversity (read exceptions) that technology vendors throw at you.



You seem pretty wrapped around the axle about a switching (layer 2) technology in your layer 3 device. Don't over-think it. pfSense has zero concept of what a PVID is. That is up to your switching infrastructure.

I'm struggling to keep people from getting wrapped up in the switch fabric, because the quickest argument is to force some other element of the infrastructure to negate the question, which is avoiding the question as opposed to answering it.

4
You simply don't do that in pfSense because pfSense has no support for such VLAN tag manipulation, in other words no support for PVID functionality or any related tricks that you'll find in a VLAN capable switch.

I'm not trying to do any kind of 802.1q manipulation at all. To the contrary, I am explicitly saying that no 802.1q manipulation is going to occur prior to the traffic being presented to one of the pfSense interfaces. Accept the fact that VLAN trunks can, and do, have untagged traffic otherwise known as "native". Any 802.1q aware device needs to have a strategy if it's going to "handle" native traffic, otherwise it just falls on the floor. A common strategy would be for the device to treat untagged traffic as if it had been tagged with a device dependent ID.

When I say handle I am explicitly talking about a device that makes decisions based on knoledge or assumptions, for example assuming that untagged traffic should be logically routed to a pipeline dedicated to a default ID. In the case of a firewall you want to handle the traffic by assigning it to a specific interface, because that's how pfSense works; it breaks a VLAN trunk out into a series of virtual non-802.1q interfaces. In fact, if the traffic happens to be routing across subsets, which usually also implies routing across VLANs, the packets will be re-tagged on the way out... or if it was untagged to begin with it will get tagged.

5
em0 is untagged

Isn't em0 everything? I'm under the impression that em0_vlan100 is a subset of em0, so em0 "would include", but is not explicitly constrained to, untagged?

Thanks for trying to focus on the question.

6
vlan 1 is the default on any switch.. The device doesn't give 2 shits what that ID tag is..

I'm sorry, but that is not correct. On Cisco products, that support it, you would set the default VLAN ID, to 666 for example, like so
Code: [Select]
switchport trunk native vlan 666
"some switches can tag untagged trunk traffic"

Huh??  That makes no sense..

It makes perfect sense. When a switch encounters untagged traffic on a trunk port it can do nothing at all and just pass the traffic as-is, or, it can add some default tag before sending on it way. Not all switches have that ability.

How do do what with pfsense???  Pfsense interface gives 2 shits what the switches port native vlan or untagged is..  It can be anything you want it to be, either the default vlan 1, or whatever you change it to on the switch.

I think I was quite clear on what the question was. I'm not going to repeat myself.

You sure do not need a full managed switch to do this.. even the cheapest of cheapest smart switches will allow you to change the native or untagged vlan of a port.. That is the whole freaking point of a vlan switch.. Common term for this is PVID.. (Port VLAN ID)

I'm afraid that you're confusing VLAN Trunks with Access Ports... and we're not talking about switch fabric (or at least I'm not), we're talking about a specific firewall/router.

7
How would you configure an interface for the native/untagged VLAN in a trunk? Each vendor seem to have their own way to go about it... Cisco, for example, defaults it to ID 1, but you can change that on some products.

I think people get confused because native/untagged has no ID, so most devices have some way of assigning their own logical ID so that you can reference something that by it's very nature has no intrinsic reference.

Also, some switches can tag untagged trunk traffic, so if you're down stream from that you'd use the switches default ID. So yes, I could probably get a good managed switch to make this a moot question, but I am interested in how you would do it with pfSense.

TIA

8
NAT / Re: Outbound SIP traffic: How to
« on: February 17, 2017, 02:58:42 pm »
It was necessary to force the trunks to use a static SIP server port. The phones can be dynamic but the trunks need to be static.

Then I just used an alias for the providers IP blocks - they have 10 C-blocks - and an alias for VoIP port ranges (5060 and 10000-20000).

Then set up symmetric NAT, meaning, equivalent inbound and outbound mapping rules, except the outbound is 5060 only where as the inbound uses the alias.

A lot of the problem was actually the provider. They replied to the dynamic port during call setup, but for tear down they were sending the BYE to 5060.

9
NAT / Outbound SIP traffic: How to
« on: February 16, 2017, 09:17:53 pm »
What is the correct way to configure NAT and FW for outbound SIP from a SIP server?

Right now I have no problem with the call setup. When the server performs the call setup the outbound SIP traffic establishes a UDP state which allows the SIP replies from the remote server... then the RTP stream starts up and the lack of continued UDP traffic allows the UDP state to expire, so when the remote servers attempt to tear the calls the packets end up in the fail logs. Due to the dynamic nature of the source port you can't set a static forward rule. The call gets torn down anyway 30 seconds after the RTP stream ends... assuming that remote server was trying to say BYE. There are cases where it might be trying to say something else, at which point bad things start to happen. I've just gotten fed up with it only working 98% of the time.

10
You know it's getting really bad when you spend sleepless nights desperately trying to solve a tough firewall issue, only to eventually find the most useful information in all of the internet ends up being a solution to your exact problem which you yourself wrote four years ago.

https://forum.pfsense.org/index.php?topic=48891.0

The PXE boot still is not working, but the proxy appears to be passing traffic now. I will write this up as a bug/feature this time since I never got any feedback the last time, and then I forgot about it.

11
So, I've narrowed some tings down:

  • TFTP definiently uses ephemeral ports. That's not some configuration anomaly, it's expected behavior.
  • If this were Iptables on CentOS the answer would be ip_conntrack_tftp module, which apparently knows how to properly track the ports in the traffic and dynamically adjust the firewall accordingly, at least in theory.

So, how can TFTP work through pfSense under these conditions?... and is the TFTP-Proxy supposed to help with that?

With the TFTP-Proxy disabled on these interfaces the exchange looks like this:

Code: [Select]
192.168.4.14:69 <- 192.168.2.177:2072  [Initial request]
102.168.4.14:33526 -> 192.168.2.177:2072  [Acknowledge]

Generates an ICMP Destination Unreachable, Port Unreachable

and this one log entry:

Syslog message: LOCAL0.INFO: Jan 20 17:45:47 filterlog: 170,16777216,,1425503669,lagg0_vlan2,match,block,in,4,0x0,,64,61970,0,none,17,udp,42,192.168.4.14,192.168.2.177,33526,2072,22

With the TFTP-Proxy enabled it rewrites the source address and generates slightly different logging:
Code: [Select]
[code]192.168.4.14:69 <- 192.168.4.250:50136  [Initial request]
102.168.4.14:59199 -> 192.168.4.250:50136  [Acknowledge]

Generates an ICMP Destination Unreachable, Port Unreachable

and these two log entries:

Syslog message: LOCAL0.INFO: Jan 20 18:19:04 filterlog: 217,2,90185.1,0,lagg0_vlan2,match,pass,out,4,0x0,,64,44778,0,none,17,udp,55,192.168.4.250,192.168.4.14,50136,69,35

Syslog message: LOCAL0.INFO: Jan 20 18:19:04 filterlog: 170,16777216,,1425503669,lagg0_vlan2,match,block,in,4,0x0,,64,43330,0,none,17,udp,42,192.168.4.14,192.168.2.177,59199,2071,22

12
I'm trying to do PXE boot across pfSense and it's not working. The TFTP request makes it to the server okay, but pfSense rejects the return traffic. The thing is, the TFTP server is just replying to the original source port (2070), but the complaint is an active ICMP Destination Unreachable, Port Unreachable.

What may be important is the TFTP server is not replying from the original destination port (69). The xinetd service listens on port 69 (TFTP), however, I believe that when it accepts the inbound request, it starts the in.TFTP service, which binds to a random port. So the conversation is like this:

Code: [Select]
69 <- 2070
46539 -> 2070

As long as both machines are on the same segment everyone is happy and the transfer succeeds - clients reply to the last source port they saw, not 69 - but across pfSense acknowledgements don't come back... and I presume that's because it's checking the source port. I'm using CentOS so that TFTP server is
Code: [Select]
tftp-hpa 0.49, with remap, with tcpwrappers
So, I'm not using NAT here; all these segments are routable, so I can't see why I'd need TFTP-Proxy. Nor, do I see how I can disable it since once a line has been selected in the combo box it's impossible to deselect the last one. And, while it's not selected on any of the adapters in question, I see evidence of it rewriting traffic in the network traces.

So, I see what is happening, but I don't really know how any of this is really supposed to work.

13
General Questions / Re: CIFS: Pathetic performance across pfSense
« on: September 14, 2015, 06:39:37 pm »
It just occurred to me that I had a traffic shaper enabled, specifically CODELQ. I tried to delete those queues, but after applying changes I lost all connectivity with the box. I used the console to restore to a point before I delete and then restarted the box. After I got control back I deleted it again, and this time they are gone and the box is still running.

I repeated the CIFS test and the performance problem seems to have been resolved. But now the question turns to why would the traffic shaper do that?

14
General Questions / Re: CIFS: Pathetic performance across pfSense
« on: September 14, 2015, 05:36:28 pm »
This is the /etc/fstab entry:

Code: [Select]
\\MyServer\MyShare /mnt/win cifs user,uid=500,rw,suid,username=MyUser,password=MyPasswd 0 0
I believe it's actually SMB (over port 445). Of course, Windows is far less transparent regarding the protocol it's negotiating.

Wireshark reports the following SMB Service Response Time Statistics:
Code: [Select]
SMB Commands
Index  Procedure  Calls  Min SRT   Max SRT   Avg SRT
    47  Write AndX  1000  0.007591  0.058489  0.016606
    50  Trans2         4  0.000328  0.025732  0.006738
     4  Close          1  0.000463  0.000463  0.000463
     5  Flush          1  0.000230  0.000230  0.000230
     
Transaction 2 Sub-Commands
Index  Procedure      Calls  Min SRT   Max SRT   Avg SRT
     8  SET_FILE_INFO      2  0.000328  0.000410  0.000369
     5  QUERY_PATH_INFO    1  0.000481  0.000481  0.000481
     6  SET_PATH_INFO      1  0.025732  0.025732  0.025732

It also gives the following overall statistics:

Code: [Select]
Avg. packets/sec  1201.671
Avg. packet size  995 bytes
Bytes             70666546
Avg. bytes/sec    1195960.346
Avg. Mbit/sec     9.5868

15
General Questions / CIFS: Pathetic performance across pfSense
« on: September 14, 2015, 03:01:29 pm »
I am experiencing significant performance problems with CIFS traffic traversing pfSense. Meanwhile iSCSI traffic has no issue, nor does CIFS traffic on the same subnet.

This is a CIFS performance example on the same subnet:

Code: [Select]
(root@vm4srvp01:/mnt/win/Images)# dd bs=64k count=1000 if=/dev/zero of=test conv=fdatasync
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 1.11347 seconds, 58.9 MB/s
(root@vm4srvp01:/mnt/win/Images)# dd bs=64k count=1000 if=/dev/zero of=test conv=fdatasync
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 1.11088 seconds, 59.0 MB/s
(root@vm4srvp01:/mnt/win/Images)# dd bs=64k count=1000 if=/dev/zero of=test conv=fdatasync
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 1.13448 seconds, 57.8 MB/s


This is an iSCSI performance example on the same subnet:

Code: [Select]
(root@vm4srvp01:/vmware)# dd bs=64k count=1000 if=/dev/zero of=test conv=fdatasync
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 0.937938 seconds, 69.9 MB/s
(root@vm4srvp01:/vmware)# dd bs=64k count=1000 if=/dev/zero of=test conv=fdatasync
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 0.929954 seconds, 70.5 MB/s
(root@vm4srvp01:/vmware)# dd bs=64k count=1000 if=/dev/zero of=test conv=fdatasync
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 0.931392 seconds, 70.4 MB/s


This is an iSCSI performance example traversing pfSense:

Code: [Select]
(root@my1mdbp01:/mnt/db)$ dd bs=64k count=1000 if=/dev/zero of=test conv=fdatasync
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 0.863001 s, 75.9 MB/s
(root@my1mdbp01:/mnt/db)$ dd bs=64k count=1000 if=/dev/zero of=test conv=fdatasync
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 0.752081 s, 87.1 MB/s
(root@my1mdbp01:/mnt/db)$ dd bs=64k count=1000 if=/dev/zero of=test conv=fdatasync
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 0.720176 s, 91.0 MB/s


This is an example of the CIFS issue when traversing pfSense:

Code: [Select]
(root@my1mdbp01:/mnt/win/Images)$ dd bs=64k count=1000 if=/dev/zero of=test conv=fdatasync
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 55.074 s, 1.2 MB/s
(root@my1mdbp01:/mnt/win/Images)$ dd bs=64k count=1000 if=/dev/zero of=test conv=fdatasync
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 55.0722 s, 1.2 MB/s
(root@my1mdbp01:/mnt/win/Images)$ dd bs=64k count=1000 if=/dev/zero of=test conv=fdatasync
1000+0 records in
1000+0 records out
65536000 bytes (66 MB) copied, 55.0715 s, 1.2 MB/s

So, this appears to be a protocol problem, and not an infrastructure issue, since there is no bandwidth limitation. This issue was first noted on two different Windows 7 clients, before being testing on the Linux box, so this issue is not specific to a particular OS or flavor. About the only thing in common is the pfSense box.

Any clue what might be causing this?


Pages: [1] 2 3 4 5