Unable to Access WebGUI
-
Hello everyone.
I'm giving the virtualbox pfsense installation another go. With that, I have followed the installation following the video from pcaddicts on youtube below:
https://www.youtube.com/watch?v=pW99TOu6Hes
My installation has gone well, however, I am still unable to access the webGUI. Not sure what is going wrong but I would like to commission your help. Here is my configuration:
Here is what when I ping from host computer:
I get the same message, 'destination host unreachable' from the guest client (virtualbox vm/win7) when I perform a ping test.
When I try to access the webGUI interface either by the host machine, or guest machine using 192.168.1.50 using https, I am still unable to pull up the webGUI.
I'm not sure what I'm doing wrong. Here is the NIC information for both my WAN/LAN nodes:
Any ideas why I can't access the webGUI? Thanks in advance for any/all help.
-
WAN and LAN IP look like they are in the same subnet. That won't work - on VM or real hardware. The routing gets very confused about how to reply to a client (on WAN or LAN?)
Then, if you configure both LAN and WAN at install time, you have to get a device with browser on the LAN side of the VM, so it is allowed GUI access. -
Phil, thanks for lending a hand.
I'm still not having any luck. Here's what I did:
LAN > em1 > 10.0.1.2/8
I ensured as you said, that the WAN/LAN are on different subnets. Also, my pint tests from both host/guest now read 'destination net unreachable'. I take it that my router is prohibiting me from seeing the class A subnet? Think maybe I need to tinker with my router maybe. What's your thoughts?
-
A /8 subnet is probably far bigger than you need, I'd stick to /24 unless it really is required. That's not your problem though.
After changing the LAN subnet it's sometimes necessary to reboot the machine to flush out all the references to the old address.Does the guest VM correctly receive an IP address via dhcp from the pfSense VM?
The host computer is probably not connected to the internal virtual switch so you would not be able to ping from that without opening a firewall rule on WAN.
Steve
-
You spoke of a host and guest computer not being able to ping its target.
If the LAN interface (on the pfsense VM) is an internal interface and not bridged, you shouldn't be able to ping it from the host or a physical computer on the same LAN as the host.
Only another VM on that host machine using the same intnet as its interface should be able to see that PFsense LAN interface.
It would be like you at your home trying to ping my LAN just because we are both on the internet.
There are layers of NAT in the way.1. Don't run pfsense on virtual box unless you only plan to use it as a firewall for VMs running on the same machine.
2. Save yourself some headache. Don't bridge your WAN and LAN to same interface. Sure, there are some cases you can do and get away with it, but why inflict that headache on yourself?
3. Most people having success with virtualized pfsense to be firewall for both physical and virtual clients are using EXSi.Thats all I'll say about that.
-
For testing, I often use VirtualBox on Windows. I first install a test pfSense VM with just WAN connected to the same real NIC that the host Windows PC is using. In that config, pfSense puts the "allow all" rule on WAN (1-armed "router"). The test pfSense VM gets a DHCP IP from the real LAN that the host Windows PC is on (often that is a production pfSense giving out the DHCP, so I can static map it and then I know what IP the test pfSense gets). Then I can access the test pfSense webGUI via its WAN IP. I add my own pass rules on WAN (so I can get into the webGUI, ssh etc as needed). Then I assign the "intnet" to LAN. The allow all rule moves to LAN. Then I can make another VM to connect inside "intnet" and can use that as a test client.
You do need to think about what is connected in of front and behind what, and not get yourself locked out from a network on the wrong side. -
I do the exact same thing as you Phil, however, I get the distinct impression (perhaps I'm wrong) that he is attempting to ping or connect or make other machines client to that pfsense LAN side, vs opening some ports on the pfsense WAN and accessing that. I think the easiest way for him to test drive pfsense in VM with virtual box would be for him to make his pfsense LAN subnet something that isn't used anywhere else, like 10.13.32.1/24 and then create a second 1 core low ram VM and give it an internal interface (not bridged), name the interface intnet and have it grab DHCP from pfsense.
Then he could play around with ubuntu as client to pfsense and it would very closely resemble what he would get if he actually switched to pfsense as his core firewall/router. (Double NATed - but just for giving it a test drive) -
The purpose of running pfsense on virtualbox is to create a firewall for internal VMs. My plan is to use pfsense as my firewall and then create MS server edition guests to create an internal private LAN. Pfsense will initially be my starting point for the VM server/client guests beneath it.
Ok, I'm still having difficulties so here is the breakdown:
My WAN port is getting its bridged IP address automatically from my modem which has switching capabilities (four physical ports). When I ran the installer, pfsense grabbed 192.168.1.203 automatically, I believe from my modem (which is by default, a DHCP server since it is used for a wireless LAN/physical LAN).
I go to ping 192.168.1.203 from either the host machine (hosting pfsense) or another guest machine (VM) and still unable to ping 192.168.1.203 (still in bridged mode). I would imagine that I could ping 192.168.1.203 (which is set to bridged mode in virtualbox) as any other client running in within the LAN network but my ping tests are coming up with dropped packets. Same goes for the LAN address (set to intnet), but as you said, I wouldn't be able to ping that address from my host machine.
Oh, and I've tried linking my WAN address directly to my IP address, directly to my router address, directly to the IPv4 Virtualbox LAN adapter, directly to my host machines IP address with no luck.
I don't know what's going wrong, but I'm determined to make this work. I've seen pfsense work and am totally impressed with it. Once I figure out this problem, I have many projects for the firewall in the works. Thanks for your ongoing efforts.
-
"My WAN port is getting its bridged IP address automatically from my modem which has switching capabilities (four physical ports). When I ran the installer, pfsense grabbed 192.168.1.203 automatically, I believe from my modem (which is by default, a DHCP server since it is used for a wireless LAN/physical LAN)."
Yes - No problem there
"I go to ping 192.168.1.203 from either the host machine (hosting pfsense) or another guest machine (VM) and still unable to ping 192.168.1.203 (still in bridged mode). I would imagine that I could ping 192.168.1.203 (which is set to bridged mode in virtualbox) as any other client running in within the LAN network but my ping tests are coming up with dropped packets. Same goes for the LAN address (set to intnet), but as you said, I wouldn't be able to ping that address from my host machine."
You Should be able to ping PFsense's WAN this way assuming ICMP is not blocked AND PROVIDING YOU HAVE GONE INTERFACES > WAN BOTTOM OF PAGE AND UN-CHECK "BLOCK PRIVATE IP". I'll go ahead and bet you have not done that.
OK - Lets stop here and let you make sure ICMP and private address are not blocked then once you do that, see what else you need.
-
Actually - You will not be able to access the web gui to make those changes. :'(
So, in your pfsense console. Select 8 (shell)
Now - deactivate firewall
pfctl -d
Now from host machine, try to access the pfsense VM via its WAN on a web browser by typing in web browser either
http://192.168.1.203 or
https://192.168.1.203Depending on what you are using.
Go in and change the WAN interface as I said before. uncheck "block private"
Now, go to firewall > rules > WAN.
At the Top, make yourself 3 rules to allow SSH on port 22, HTTP on 80 and HTTPS on port 443.
Make sure those rules are at top above any block rules.
You will probably also want to go into advanced > and Disable DNS Rebinding ChecksThat should get you going.
Now, in the pfsense shell command, type:
pfctl -eTo re-enable firewall.
Try it out.
Now, anytime you accidentally lock yourself out with firewall rules, you can use "pfctl -d" to get back in through the WAN.
Make your changes to allow yourself access then pfctl -e to bring the firewall up againDo that much, then lets see whats up.
You have other issues for sure that are easily resolved, but first get this much working. -
kejianshi, I owe you one. Sincerely, thanks for taking time to help me out with this. I met your team at the SELF conference last month and was impressed on how helpful and excited you guys are about pfSense technology. You going the extra mile to continue to help me is not surprising, just shows how dedicated you are and the passion you have for this awesome technology. Anyhoo, I've got more to report.
Now, here's the interesting part. Once before, I was able to access the WebGUI, however, it was only because WAN was the only interface assigned (no LAN or em1 assigned).
I went through each of your suggestions but didn't come up with anything.
Now, I know at least this much. My host firewall is not prohibiting me from accessing the WebGUI. The problem is only happening when I enable em1/LAN card, which then takes the WebGUI offline. As you seen from my screenshot, LAN/em1 is simulating Intel PRO / 1000 MT Desktop, just the same as the WAN bridge adapter em0.
I'm happy now that at least I can access the WebGUI, but now I have to continue to trouble shoot why exactly I'm being kicked off when I add the LAN card set to intnet within virtualbox. It just doesn't make sense. I plan to try a different interface type, specifically using maybe using an different Intel or AMD interface.
Stay tuned.
-
Well, I know the rest of the answer also. Remember I said there was more to do?
BTW - I'm not with the PFsense crew, but I did stay in a holiday inn express last night.
I do think they have come up with a great thing.
They are smarter than me with this though. This would be their "lite work".For the next part, we need to make some changes to you LAN port on pfsense and also your client VMs.
I'll type abit about that after I take the kid for a walk. I just rebuilt a dryer for last hour… So exciting. -
Ha! You're funny.
Anyway, I appreciate you working me through this and being so giving. Maybe I can figure out a way to buy you lunch.
More tinkering to do with this after work tomorrow.
Again Sir, thank you much.
-
pfSense is a firewall - it defaults to keeping out the nasties on the public internet side.
a) When there is WAN and LAN, then everything originating on WAN is blocked by default. In production, this is always what you want (then you add rules to open up the specific things that you want outside internet to be able to access).
b) When there is just WAN (unusual/special config), then access is allowed to webGUI (and a few ports - I won't try to specify them exactly here) on WAN.
So, you can get in when there is just WAN. When you add LAN, then the webGUI "anti-lockout" rule moves to LAN, and you lose access from WAN. This is usually what you want.
To keep WAN access, then, before adding the LAN interface, add pass rules of your own on WAN to allow the things you want. (For ease in testing, allow all, but in production if the WAN faces the real internet, don't do that!)
-
Could easily end up with 'too many chefs' in this thread and just confuse things further but let me just say that everything you have described is exactly what I would expect to see. Your setup is behaving perfectly, you don't have any random weirdness to deal with. ;)
Kejianshi seems to have this under control. :)
Steve
-
Well - Next step, as I see it, will be getting his VMs that are to be client to the PFsense un-bridged from the Host's network and on the internel network. I'd like to see the client VMs get DHCP from intnet and I'd like to see intnet given a sane subnet. After the VM clients can access the pfsense LAN side he can close the gaping security holes that are there just to give him gui access from the host machine. Then he should be able to admin his system from the VM clients same as any network using pfsense (Still the issue of double NAT - Talk converting to typical pfsense setup later)
-
Hey guys.
Well, got to do some more tinkerin' ;D
As per kejianshi:
Well - Next step, as I see it, will be getting his VMs that are to be client to the PFsense un-bridged from the Host's network and on the internel network. I'd like to see the client VMs get DHCP from intnet and I'd like to see intnet given a sane subnet.
Yes, this is my intent. Ideally, I'd just like to get it up and running (making em1 a dhcp server) so that I can create my own internal network of VM servers and hosts.
To keep WAN access, then, before adding the LAN interface, add pass rules of your own on WAN to allow the things you want. (For ease in testing, allow all, but in production if the WAN faces the real internet, don't do that!)
Phil, truly, I need to do more research. I'm amazed at all the options and the ability to modify all the granular specifics. My window to do this will largely be this weekend, however, I'm having trouble adding the pass rule.
I tried under advanced > Disable webConfigurator anti-lockout rule > added the LAN > and then was unable to access the WebGUI again.
Also, I went to firewall > rules > Single Host or Alias > 192.168.1.203 > and yet I was still unable to access the WebGUI.
Again, just to get this up and running, what would I change in within the WebGUI in order to turn on LAN intnet (DHCP node) for my LAN guests and still be able to access the WebGUI?
Cheers gents.
-
Well - Earlier, I gave you a couple of commands to shut down and then reactivate the firewall rules if you ever locked yourself out with a firewall rule change. So, if you locked yourself out, use:
pfctl -d
Then go into the web gui and change back whatever firewall rule you changed that locked you out.
Then.
pfctl -e
Next, to get your intnet on your pfsense handing out DHCP, you will need to go to your Interfaces > LAN
Make sure its static type.Then give it an IP like 10.14.73.1 / 24 (Thats just a random IP. Pick anything you like in the private IP range)
Make sure gateway = none.
Make sure you are applying setting.
Then you have to go into services > DHCP server
click the LAN tab. Check the activate DHCP button.
Now give an DHCP range like 10.14.73.50 - 10.14.73.200
(This determines the start and end point for IPs auto assigned by DHCP Later you can add static IPs above and below this range if you like)
Apply settings…
Now, you have a DHCP server and a sane IP range for a LAN
To be sure this doesn't cause issues, make sure the LAN Ethernet interface you added in your isn't bridged. You want that one internat network. (intnet)
Now, to get the other VMs to get their IPs from pfsense you will also have to change their network adapter setting to internal also with same name (intnet).
Assuming you do all those things and don't typo and no crazy unknown circumstances, you should have a network.
Should be able to access the pfsense web gui from your VM's web browsers.
-
Again, just to get this up and running, what would I change in within the WebGUI in order to turn on LAN intnet (DHCP node) for my LAN guests and still be able to access the WebGUI?
Before enabling LAN, add a pass rule to WAN, and might as well enable SSH:
a) Add an alias for ports HTTP (80), HTTPS (443) and SSH (22) - e.g. call it MgmtPorts
b) Add rule on WAN: Pass, IPv4, protocol any, source WAN net, port any, destination WAN address, port MgmtPorts.
c) System->Advanced, Admin Access, Enable Secure Shell.Now you can always come from the WAN network side to the webGUI, or ssh in to the WAN side and get a command prompt.
Now enable the LAN side.
-
Bang! Bingo! Kaboom!!!
That got it guys. Cheers to all of you.
I have successfully been able to pass the intnet to my virtual machines and can also access the WebGUI from both my host/guest machines.
I noticed that I had to turn off the firewall after I had added the LAN, but no biggie. Now that I have the bridge from WAN to LAN, I can now do some experimenting and also take a few classes on working with settings and advanced configurations.
I'm so happy. It's truly cool to be able to now have a firewall/router that I can tinker with, set up rules, keep the bad guys out, etc. This is going to be fun now that I have the box up and running and can now feed the internet off to my servers/hosts. What's also cool is that I will be able to discover some of the more advanced aspects of networking, for which I only have a foundation currently as a professional.
Thank you all. Thank you all again. Now that you all have been giving to me, I hope that I can return to others the same.
