LAN GUI not accessible!
-
Wait - I do see a POTENTIAL problem on the interface > LAN. Its given a /16. Shouldn't it get a /24?
Assuming you are aiming for a simple configuration.
It is a definite problem - LAN 192.168.2.10/16 is a router sitting in the middle of the whole of 192.168.0.0-192.168.255.255
Then the WAN IP that you "happen" to be given by DHCP on WAN is 192.168.1.n with gateway 192.168.1.1 - that is inside LAN, so the routing will not work properly.
When connecting a private-address-space LAN to an upstream "WAN" that is actually another chunk of private address space, you do have to engineer it to make sure the 2 subnets do not overlap.Change LAN /16 to /24 and I expect it will all go.
-
A /24 includes, for example, 192.168.1.x
A /16 includes, for example, 192.168.x.xSo, unless I'm groggy headed today (It happens often) your LAN net is somewhat inclusive of your WAN net. But if you changed the /16 to a /24 it shouldn't be.
What can it hurt to change it? If you don't like what happens, change it back.
-
I'm trying to be soft and cuddly vs. my abrasive direct self… haha
-
Right so I've changed the subnet on my LAN back to /24 and changed my firewall rules from /16 to /24 and everything is working the same way as it was.
I have access to the webgui via WAN and LAN, I can ping out but not in and my gateway is still apparently offline.
Still no internet :(
Name = WAN_DHCP
Gateway = 192.168.1.1
Monitor = 192.168.1.1
RTT = 0ms
Loss = 100% -
Perhaps, but you are now closer to a working configuration. Did you turn off IPV6 for now?
And can I see your WAN firewall settings?
-
Perhaps, but you are now closer to a working configuration. Did you turn off IPV6 for now?
And can I see your WAN firewall settings?
Just incase i'm being really stupid, I've attached a picture of my network adapter IPv4 settings within my virtual machine aswell.
-
I'm sorry - I see your LAN and WAN rules. My internet is abit slow here.
WAN look OK (for now)
LAN has ALOT of rules that seem to me are totally not needed and doing about nothing.I'd get rid of them except the 1st grey one and the last 2 default rules.
The rest seem to not belong.
After that, I'd reboot pfsense.
-
I'm sorry - I see your LAN and WAN rules. My internet is abit slow here.
WAN look OK (for now)
LAN has ALOT of rules that seem to me are totally not needed and doing about nothing.I'd get rid of them except the 1st grey one and the last 2 default rules.
The rest seem to not belong.
After that, I'd reboot pfsense.
Again, same situation. Everything works apart from the internet! :(
-
Well - 1st, I would let DHCP assign the IP and DHCP for windows VM.
But if you are going to assign it manually, put the IP of the windows machine outside the pfsense LAN DHCP range.
Then give the windows DNS server IP the LAN address of pfsense.So, 192.168.2.10 for your DNS Server (Assuming you will let pfsense forward DNS, which is a smart thing to do usually)
-
Well - 1st, I would let DHCP assign the IP and DHCP for windows VM.
But if you are going to assign it manually, put the IP of the windows machine outside the pfsense LAN DHCP range.
Then give the windows DNS server IP the LAN address of pfsense.So, 192.168.2.10 for your DNS Server (Assuming you will let pfsense forward DNS, which is a smart thing to do usually)
You sir, are fantastic!
All this hassle was simply because I had not allocated my secondary DNS as 192.168.2.10!
Thank you so much for the help :D
-
I'm thinking you don't quite get what is going on yet, but you are getting closer…
NAT comes in layers in your case and so can DHCP and DNS for that matter...
So your 1st layer, as far as we know is the university network. They are then assigning an IP to pfsense WAN via DHCP and DNS via DHCP (we hope)
So pfsense then becomes your second layer of NAT and it can then assign IPs via its DHCP server and DNS to anything on its LAN...
Or you can tackle it manually. Your call.
-
Ohhh - Glad it works now…
Us forum wreckers do what we can.... (-;
Sorry if I gave you the wrong impression with my comment earlier.
Just trying to find the core of the issue.
Let me know if you have more issues.
-
This is getting complex! Not helped by the fact that I have sent a few PMs with ForensicGeek so that info isn't available here. ::) Let's keep things public.
The fact that the gateway is showing as down is not good and probably explains why routing is not happening. The gateway status is monitored by pfSense pinging the gateway address so it implies either the gateway is not responding to pings or it can't reply for some reason like a bad route. What is the gateway address? I assume it's a machine on your Uni network. If it's running IDS/IPS it may have objected to the constant pings and stopped replying.
A few things are unclear to me reading back through the thread. So for the sake of clarity:
You are using a single physical host machine and pfSense (and others) exist as VMs running in VirtualBox, yes? You seem to have used the term 'virtual box' where I would expect to see 'virtual machine' which is confusing (to me ;)).
I'm not sure where or how you are testing that things are 'working'. Are you testing from a VM behind pfSense?I have only used virtual box a few times but on each of those occasions the thing that tripped me up was assigning the correct network adapter type for host communication. As I recall the nomenclature used did not make it obvious and the docs were also unclear.
Steve
-
Unless I misunderstood, its working for him now.
-
Yes but I fail to see how adding a DNS entry to one of the VMs will have fixed the pfSense gateway issue. Also 192.168.1.1 should have worked as a DNS server for that VM anyway, unless the WAN gateway is not a DNS server. In which case what is it providing for DNS via DHCP on the WAN?
I agree that there seems to be something more here. We shall see. ;)P.S. W00t! 10K posts. ;D
Steve
-
[[quote]P.S. W00t! 10K posts. ;D
So are you trying to post all over just to catch JimP? -
Do your fingers hurt? ;D
-
Just kind of happened. ;)
Steve
