Can't get VLAN working on DD-WRT or Netgear - no traffic
-
I have a Qotom 4port box with an intel i211 controller and have checked it does support VLANs
https://ark.intel.com/content/www/us/en/ark/products/64404/intel-ethernet-controller-i211-at.htmlI created a VLAN
igb3 (opt1) 27 4 VLAN_27_MEDIA
igb3 is assigned as 192.168.27.10 / 24created firewall rule all protocols, any to any for testing
I enabled DHCP with a pool from 27.40 - 27.45 for testingDD-WRT on WDR-3600 v1 N
i had to setup from scripting and put WAN and port 5 on VLAN 2 and ports 2 - 4 on VLAN3
VLAN1 0t 1t
VLAN2 0t 1t 5
VLAN3 0t 1t 2 3 4- from port 5 i can browse internet
- from port 2 without vid = 27, i obtain DHCP and can reach the wdr3600, but with rules, still can't reach outside
- when i add swconfig dev switch0 vlan 1 set vid "27";
- internet on port 5 stops working - but can still reach the dd-wrt
- windows pc can't obtain DHCP
also tried creating as vlan27 without manually setting vid but same results
tried manual IP and tried to reach dd-wrt and pfsense.
could reach either with vid27, could reach dd-wrt without vid27 assignedwas struggling for ages and decided and better keep it simple, and try the netgear not in service to confirm all was working.
netgear gs110tpp
VLAN ID 27, VLAN_27_MEDIA, staticMembership
ID1 all untagged port 7 removed
ID27 port 9 tagged, port 7 untagged all others removedPVID config
ID1, PVID1, VMember 1, Admit All, Ingress disable
ID27, PVID27, VMember 27, VLAN Only, Ingress disablei get the same thing link with dd-wrt unable to obtain a DHCP.
tried manual IP and tried to reach pfsense to no avail- Packet Capture shows no traffic at all on the VLAN
-
@gwaitsi made some progress on the netgear.
- client in vlan obtains dhcp from pfsense and i can ping pfsense from the client, but
- pfsense cannot ping the client
- and client can not ping or route via the default gateway,
so only seeing dns related packets on the vlan interface.
looks like i have something missing on the netgear side, but not sure what.
-
@gwaitsi said in Can't get VLAN working on DD-WRT or Netgear - no traffic:
Packet Capture shows no traffic at all on the VLAN
so only seeing dns related packets on the vlan interface.
Well how could that be? Makes no sense and not possible.
-
@johnpoz i don't know, the original problem blocking DHCP was the security on the netgear had MAC locking and DHCP snooping enabled. I disabled both and was able to get a DHCP on the client and could ping all the interfaces on pfsense.
I copied the rules from the LAN to the VLAN interface, which should allow tracert, ping and http out.ping from pfsense vlan interface to the client works,
but not from a client on the lan to the vlan client nor from pfsense with the source as the LAN addressi think it is something to do with the netgear vlan gateway. but the client dhcp points to pfsense as the gateway, so i don"t get it
-
Lan default is any any.. so it can talk to anything it wants... Host firewall on your vlan could be blocking Pings from outside its network.. This is default for example on a windows client.
Why would there be a vlan gateway?? You running this as downstream router? There is no gateway on the vlans on a layer 2 setup. And if your doing layer3 and routing on the switch, then the only gateway would be on the vlan connected to pfsense.. none of the other vlans would have any gateways setup.
-
@johnpoz is not the pfsense the gateway out.
the pfsense provides DHCP and the gateway and dns are the pfsense vlan interface address, or am i doing it wrong?
e.g. pfsense LAN x.x.20.1
VLAN30 x.x.30.1netgear LAN x.x.20.2
VLAN30 x.x.30.2DHCP LAN srvs 20.1 as DNS and gateway
DHCP VLAN30 srvs 30.10 as DNS and gatewayPC picks up either x.x.20.40+ or x.x.30.40+ depending on switch port
both tracerts dns resolve to the same address x.x.65.67-
if i tracert from a client on the LAN x.x.10.x to VLAN30, i get a response from the pfsense interface 10.1 but timeout after that. that is true whether the switch address or a client on VLAN30.
-
if i tracert from a client on the LAN x.x.10.x to LAN20, i get a response from the pfsense interface 10.1 but timeout after that if a client. however. i get a response from the switch if the destination of the tracrt is the switch.
-
if i tracert from the client on the LAN x.x.20.x to the LAN 10 client i was using for the revers, i get next hope pfsense LAN20 interface, then client on the 10.x success
-
if i tracert from the client on the LAN x.x.20x to the internet, next hope is the vpn interface address and success
-
if i tracert from the client on the VLAN30 to the internet, i get timeout
-
if i tracert from the client on VLAN30 to the LAN 10 client, i get next hope VLAN30.1 and then the client success
so it works in some directions, but not the others. i am not clear from this if the problem resides on pfsense or the netgear
interestingly, there are only 4 entries in the VLAN40 log. all to allow from the client to 239.255.255.250:3702 but nothing else.
*** so took the switch out and configured the win10 machine with the vlan id. and repeated above. same problems.. so it is on pfsense where i have the problem
- don't know why i didn|t think to add a direct PC sooner. but rules shows ICMP pass from VLAN30 PC to client on LAN 10.x, however the PC shows time out. same with http as well. all shows allowed in the rule logs.
i might add, if i use diagnostic traceroute with the source address the vlan and destination lan 10.x client, it times out
-
-
Why and the F are you hiding rfc1918 space - come on.. Do you want help or your worried I am going to hack you with your 192.168.20.1 address? or 10.10.20.1 address? Are these actual public IPs behind pfsense that you own? And are routed to you?
How about you draw up how you want it to be, or think it should be and then we can discuss..
Why would there be vpn interfaces? Are you forcing traffic out a vpn - yeah that is going to be a problem! Can your vpn get to your other local networks? You would have to allow rules to get to your other vlans before you force traffic out some vpn
DHCP VLAN30 srvs 30.10 as DNS and gateway
What is 30.10 -- that is SVI on your switch? Or that is pfsense IP.. Again are you trying to do routing at your L3 switches or is pfsense going to be doing the routing?
If you want pfsense to route the traffic then all gateways would be pfsense IP on that vlan.. If you want your switch(es) to route then pfsense would be connected to them via a transit and not have a clue to the vlan IDs.. It would need gateways and routes setup for the downstream networks.
-
@johnpoz x.x is 4 characters less than 192.168 ;-) 30.10 was a typo, is be 30.1 of course
but dude, forget the switch now.
I have a win10 pc plugged directly into the pfense lan port.
it works fine in the native 20.x range. As soon as i set the vlan id to 30.
the pc has exactly the same problems as describe above. so it is nothing to do with the switch.so i fired up a new test vlan 40 and put a single any protocol, any to any rule in there.
on the LAN, the PC has no problem accessing internet (via the VPN - default route for all connections)
as soon as i add the VLAN ID to the PC adapter, i get the same test results- PC can ping to pfsense on all interface addresses.
- PC can ping to the other LAN 10 devices
- LAN10 devices can not ping to the PC on VLAN (can on LAN)
as with the other one, i set logging to the rule and the log is full of passes http/s, dns,etc
** put in first rule on LAN 10 to pass any protocol, any port to the vlan 40. with loggin
ping from shows as being allowed, just like stuff leaving the vlan but doesn't get any result.
traceroute stops at the LAN10 interface. -
@gwaitsi said in Can't get VLAN working on DD-WRT or Netgear - no traffic:
on the LAN, the PC has no problem accessing internet (via the VPN - d
So your POLICY routing out your vpn??? Post up your rules... If you set a rule that says use gateway X (yourvpn) how is it going to get to your vlan?
you need to allow vlan access before you force the traffic out a vpn..
Your rules also have to allow access to pfsense before you force it out a vpn, if yoru trying to ping your pfsens vlan IP.. also in this setup of this vpn, did you turn off automatic outbound nat? If so when you add vlans you would have to add them to the outbound nat, if you know want to actually nat to get to the internet..
-
@johnpoz not sure i understand.
- default gateway is VPNpool
on the LANs the rules are; - TCP/UDP any to LOCALAN *
- TCP/UDP any to VPNBYPASS Gateway WAN
- TCP/UDP any to !LOCALLAN Gateway VPNPool
this works on both lans
strangely, i rebooted and it was working before i went for breakfast.
come back from breakfast, now the PC is not getting DHCP form the VLANs.but once again, i see the rules are passing. e.g. ping from LAN10 client to VLAN40 client
shows in the logs as passing. but no response from either way.Nothing changed from the reboot, to having breakfast and coming back. only the time
- default gateway is VPNpool
-
@gwaitsi so... it looks like the problem is ngix
*nginx: 2019/09/29 11:58:06 [error] 83942#100301: *20 access forbidden by rule, client: 192.168.40.40, server: wpad, request: "GET /proxy.pac HTTP/1.1", host: "192.168.40.5"*
interestingly, i did not have the vlan configured to use wpad on DHCP.
What i did is;- allow the vlan subnets in the ngix conf
- in the proxy.pac added those subnets with DIRECT
I have not added 252 string... on the DHCP boot options for the vlan but the problem seems to have been resolved. I will do a few reboots and further testing to be sure, before i move beyond connected directly to pfsense, but so far i tested a couple of vlans and they seem to be working.
-
@gwaitsi said in Can't get VLAN working on DD-WRT or Netgear - no traffic:
TCP/UDP any to LOCALAN *
None of those rules allow icmp (ping) And what is locallan? A alias with what in it? Is the alias actually working, you validated in the table via diag menu that what you want in there is actually in the table?
And please just post up a screenshot of you rules...
Also ! rules, your last one there can cause you problems if your using vips.. Say pfblocker which creates a vip can cause you problems with such rules... Unless your sure and validate they work, and prob actually look at the raw rules via cmd line.. Its best to use explicit rules
Block what you want above, and then allow any any at the end.
edit: And zero mention of any proxy you setup.. And proxy not used for simple pinging..
-
@johnpoz yes, yes...of course, i have the ICMP 3x as well e.g.
ICMP any to LOCALAN *
ICMP any to VPNBYPASS Gateway WAN
ICMP any to !LOCALLAN Gateway VPNPoolso i can be sure i am seeing the way the http traffic goes for a given host. I found the ordering was critical and had to change it to get the right results.
i.e. this forum goes via the VPNBYPASS but if the locallan is not first, it wants to go via the vpn. any, that's another story. but its all goodp.s. proxy is not running at the moment, but i left the wpad config for LAN10/20 while i sorted the base.
the proxy.pac and the nginx config referred only to the two LAN segments, and had a "DIRECT" statements, save me having to do the whole thing again.
But interestingly, even though VLAN wasn't setup to use wpad, it still seems to have been affected by it having been setup for the two LANs (even is simply to pass a DIRECT) statement
-
@gwaitsi said in Can't get VLAN working on DD-WRT or Netgear - no traffic:
I found the ordering was critical
No really ;) Who would of ever thunk that? ;)
https://docs.netgate.com/pfsense/en/latest/firewall/firewall-rule-processing-order.htmlRules are evaluated on the interface the traffic will first enter pfsense, top down, first rule to trigger wins, no other rules are evaluated..
You did not state you had any icmp rules - this is WHY posting a screenshot is KEY!! Users always say they do X, but they really did Y... Users state sure I have rule that allows that, when there is a rule above it that they forget to mention that blocks it, etc. etc. etc.. Its just faster, easier, and no missing info if you just take 2 seconds to post screenshot of the actual rules or settings.
I have no idea what your doing with your proxy - you made no mention of a proxy until now.. Again the missing info part ;) So you setup proxy as transparent? Have no idea how you setup proxy.. But again proxy would have zero effect on simple ping to test connectivity..
When you ping from lan to say vlan X from device on lan... the vlan could have zero rules set on it, and you could still ping because lan is default any any, and the return ping would be allowed by the state that is created.. If you can not ping a device in vlan.. Few things that can cause that.. No rule to allow it on source network your pinging from, forcing traffic out a gateway, client your pinging not using pfsense as its actual gateway. Client your pinging has a host firewall. Client your pinging isn't even connected, or your pinging the wrong IP, etc.
-
@johnpoz as i said man, the proxy (squid) is off while i sort the other issues out. I decided to implement the vlans and ensure everything was running tight before introducing another problem point.
I set the wpad up via another ngix instance and rather than backing everything out, i just changed the proxy.pac to DIRECT for the two lan segments i had. It seems, even though the win10 wasn't configured to use a proxy, nor was DHCP one the vlan segment, nginx was still reporting an authentication error for the vlan segments. I've now added all the vlan segment to the ngix config and it with my original rules.
i have also come across an issue with win10 and the vlans. It seems when win10 is connected to pfsense and goes to sleep with a vlan config, when woken up, it doesn't have a DHCP address and can't be renewed until the adapter is disabled and re-enabled.
anyway, seems stable enough i can start again with the netgear and dd-wrt.
update: netgear and dd-wrt now good.
only strange thing is the win10 pc, doesn't get an ip after waking up on the vlan without toggling the adapter off/on. on the lan it doesn't have this problem. ** oddly enough, this doesn't happen with the PC is connected via the dd-wrt switch. Only when it is directly connected to the qotom box. strange.... but all good now