setting up pfSense on wireless 7 laptop

I realize that pfsense is really designed for dedicated hardware with multiple nics, etc... Also, I am a newbie with pfsense. If I can work this through I will.

History: I am trying to use pfsense in a VirtualBox VM with the intention of removing all connectivity from the windows 7 host once pfsense is running properly. Then if successful I will employ linux VM's that will be running and connecting through pfsense's connectivity. Why? We started a project to see if we can use TrueCrypt with a 7 hidden OS running. However; we want to remove 7's ability to communicate with the outside world. 7 will only host the VM's so that we can utilize the hidden OS feature. My final piece will be to move the hidden OS (circumventing code restrictions) to a non traditional position on the hard drive to further conceal its existence. That is the goal anyway. Please limit our discussion on this thread to PFSENSE. The other thread running can still deal with any non-Pfsense particulars.

I have Pfsense 2.0.3 installed (VirtualBox VM) but NOT configured past console view. It uses less resources than the latest version. It loads and finds wan and lan. I defined/changed lan to 192.168.1.15 and wan is 10.0.XXX (DHCP). When I start pfsense with my vpn tunnel and the 7 host OS fully connected it finds wan and lan as shown above. In console view I can select 13 - upgrade from console and it finds the files and will start to download them so it is seeing the internet at this point. I stopped the upgrade and only briefly selected that option to investigate if there was a connection.

I may be going about this all wrong. When I try and start pfsense with my internet connection down it hangs at NTP client time. That is common until I do some editing according to a few posts that I have read.

My next thing is to figure out HOW to get to the web gui. It sounds so simple but I can't get it to work. Help - lets say I am connected and pfsense is running where it sees lan and wan. Since my lan is 192.168.1.15 where do I type https://192.168.1.15 to pull up the configurator? The browser in my host 7 doesn't work. I also fired up a linux VM and the browser there doesn't work pfsense either. I am not sure of the adapter settings for the VM's yet.

Suggestions appreciated. I don't mind trying stuff that doesn't work, so don't worry about "brainstorming" approaches. I am pretty much stuck until I can at least pull up the web interface via lan. Why can't I?

 

Thought: Would defining LAN such as I have conflict with the normal LAN position in my network? If I type in my normal lan my home router control panel pops up instantly. i.e. my home router responds instantly to a browser prompt. Are these two devices (router and pfsense) fighting each other in LAN-land?

 

If your physical LAN is 192.168.1.0/24, that may be the problem.

Change the LAN IP address on the pfSense VM to 192.168.2.1 with subnet bit count 24, enable DHCP server, and use whatever address range you like (say 192.168.2.150 to 192.168.2.155).

By default, pfSense allows access to its webGUI only on LAN, just as your router should. In VirtualBox network settings for the pfSense VM, you attached adapter 2 (aka LAN) to a VirtualBox internal network. You manage the pfSense VM from a Linux desktop VM that's attached to the same internal network. It gets its IP address from the pfSense VM.

The NTP server lag typically indicates that pfSense is having trouble reaching <0.pfsense.pool.ntp.org>. You can fix that by specifying whatever addresses (separated by spaces) you get from running "host 0.pfsense.pool.ntp.org" in a terminal on the host machine.

 

Change the LAN IP address on the pfSense VM to 192.168.2.1 with subnet bit count 24, enable DHCP server, and use whatever address range you like (say 192.168.2.150 to 192.168.2.155).

DONE!

quote:
By default, pfSense allows access to its webGUI only on LAN, just as your router should. In VirtualBox network settings for the pfSense VM, you attached adapter 2 (aka LAN) to a VirtualBox internal network. You manage the pfSense VM from a Linux desktop VM that's attached to the same internal network. It gets its IP address from the pfSense VM.

response:
This is the part that is losing me. I named the internal network as xyzinternal for learning. I created an adapter in the linux VM with that address as well. The VM connects and I can go online but ---- typing https://192.168.2.1 in firefox leaves no joy. pfsense won't come up. Somehow some way I am not figuring out how to get to the pfsense lan to bring up the configurator. It might be that the linux VM is using the 7 host connection and not even glancing at pfsense.

Sorry I am having so much trouble.

 

How many adapters does the Linux VM have?

It should have just one.

VBox network settings for both Adapter 1 (the only one) of the Linux VM and Adapter 2 of the pfSense VM should look like this ...

Attached to: Internal Network
Name: xyzinternal
[no changes in Advanced]

VBox network settings for Adapter 1 of the pfSense VM should look either like this ...

Attached to: NAT
[no changes in Advanced]

... or like this ...

Attached to: Bridged Adapter
Name: wlan0 [I'm guessing here]
[no changes in Advanced]

 

Still no joy here but I have been really busy lately.

FYI - I am taking this discussion over to the PfSense forums where I have done some reading. When I have an outcome I'll come back and update this thread. I still believe that I am fighting hardware, but I know for certain that I am "too green" to know if I am. LOL!!

 

Good luck I've never gotten much joy there ;(

I can't imagine how a browser in a Linux VM couldn't connect to the pfSense VM webGUI, if the Linux VM and the pfSense VM's LAN adapter are on the same internal network, and DHCP server is running in the pfSense VM.

 

Maybe follow the tutorial at https://www.wilderssecurity.com/showthread.php?t=360906. If you try it, let me know if it works, then we can work on the rest of your requirements.

 

I feel like I have come light years along on this project. First after reading until my eyes bleed, I followed some good advice. I went to the actual pfsense mirrors and downloaded their professionally crafted OVA file. The ova was made by them and I used md5 and sha256 to verify file integrity. I had to use pfsense 2.0.3 because they didn't release an official ova for 2.1. The professional OVA running in VirtualBox fired right up and no more fatal trap errors of any kind. I changed the Linux VM's adapter to match pfsense's and I was connected immediately. Fortunately, I used a clean linux vm because I did not filter the default pfsense settings and the connection immediately went to my RAW IP. I did nothing I wouldn't do on my regular computer but at least I am out and now I can continue reading about locking down pfsense. For now I am leaving the host OS and VPN tunnel UP so I can do my research on this project. Its a great leap forward.

I have spent a great deal of time reading about how to castrate the 7 OS from connectivity. That will be the fun part, but for now I need its support until I go full scale pfsense.

I am still using 7's wireless connection but for this project to work I'll need to run pfsense wireless. That doesn't look too hard. I think my first move is to lock down the dns to my vpn's so I don't have any mistakes with an IP leak.

BTW - the configurator comes up slick and fast too. I set the pfsense LAN to something other then my normal router's LAN. I can pull up BOTH the router admin panel and the pfsense panel by keying in their respective LAN addresses in the browser so progress. Yea!!

Learning notes if others are reading along and planning on doing this. By examining the pre-made OVA (pfsense 2.0.3) settings compared to what I was reading and expecting from other threads:

Pre-configured settings:

RAM set at 1 Gig

Two Bridged Adapters named Intel Wireless XXXXXXX
adapter type in advanced was set to Intel Pro/1000 MT Server

At this point I don't know if their configs and adapter settings are why this is working. It is more likely that I built the pfsense machine incorrectly when I did it myself. The expertly made OVA is specifically designed to be used in a VM. It loads in VirtualBox slick as can be.

Stay tuned!!!!!

 

Have you found anything to suggest that unbinding everything from the host's network adapter except for "VirtualBox Bridged Networking Driver" wouldn't work?

 

Haven't considered all the options yet. We can discuss the binding when I get to that point. Would want to know 7 will not repair itself. Its really funny how many people just want to discuss "cutting the balls off" of 7. LOL!!

To be honest I don't even know why I am having so much fun working on this project. Its strictly a privacy thing for me, but now I see light at the end of the tunnel.

 

That's what's suggested in tutorials such as this.

 

Mr. Brian,

I have a "sister thread" running over at pfsense (general section). The thread is leaning towards the same conclusion as here. From a security standpoint there may be significant risks to using any 7 components to achieve connectivity. If pfsense cannot gain a connection without 7's help then I may as well just go 100% linux in both the host and the VM's. The problem is that this outcome would cost me the valued hidden OS feature.

I am not giving up, just frustrated because I think I am missing something maybe easy.

 

@Palancar: I found the thread. I didn't see anyone present any evidence that the configuration that I mentioned wouldn't achieve your goals. (Or did I miss something?)

 

The one issue I can think of is if you have a rootkit on the host, then it could possibly still access the internet.

 

Here's an off-the-wall idea. Use Debian etc as the host OS on the laptop. Then create a Windows 7 VM, using a fixed-size virtual disk, with enough space for the decoy and hidden OSs. Then, working in the Windows 7 VM, install Truecrypt, and create the hidden and decoy OSs.

That way, the Debian host would have the final say about network access.

Would that work?

 

Mirimir, you are off the normal trail on that idea. LOL!! For that to be successful/safe you have to be POSITIVE than any keystrokes and activity from within the hidden OS on the VM, would NEVER be logged on the host. I mean zero marks on the host. When you operate TrueCrypt bare metal, the software is perfectly flawless at keeping any and ALL marks inside the encrypted hidden OS. I could not arrive at a point where I would give VirtualBox that much credit for isolation.

Mr. Brian, candidly you are a little past me on my networking abilities, or specifically my understanding of the relationship between the host and the VM isolation methods. I can pretty easily setup the pfsense VM using some of your ideas. By using the windows drivers pfsense responds very well and frankly takes control. As I mentioned many posts above, it bypassed all of my OS filters and went straight to the raw IP. I understood that because I had it running default and no filters were entered at that time. That said; I feel "pfsense green" about relying upon shutting down 7's connectivity but still using its drivers. When I read your posts about it you make it sound very matter of fact. For me that is not the case and I just need to keep reading so I can attain your comfort level with the concept. Where my security is concerned I won't just "connect the dots" and feel safe. I really need to visualize and understand what is going on. I appreciate your comments and I am still reading this stuff like crazy. I would feel so much better about this if pfsense could just find the hardware and initialize all the nic's and stuff without needing window's help. But I guess that is pfsense bare metal.

 

OK, I get that. I don't know TrueCrypt well enough to trust it absolutely. Also, it's not just VirtualBox that you'd be trusting. It's Debian. Maybe you could run VirtualBox as user virtualbox, and have Debian prevent logging.

It's VirtualBox that goes straight to the hardware. Although it uses the host NIC drivers, it presents virtualized interfaces (ideally Intel PRO/1000) to pfSense. pfSense just uses what it gets from VirtualBox.

Here's another wacky idea. In researching another issue, I've come across an incompatibility between at least some Windows 8 releases and VirtualBox. Apparently, installing VirtualBox can trash the host's network connection. Perhaps, with some tweaking, that incompatibility could be useful.

 

@Palancar: I got that idea (uncheck everything from host wireless NIC except for VirtualBox driver) from other sites. I haven't actually tried it. It's not guaranteed to work 100% of the time because some software with high enough privileges could possibly bypass it, or simply undo the NIC settings that you made.

Since virtual machines don't have any physical NIC, and since a physical NIC is needed to network (right?), I don't see any way around the fact that some connectivity on the host is required.

 

But what if the non-VirtualBox drivers were not only unchecked, but also further messed up or inactivated? That's what I read about with VirtualBox vs Windows 8. To regain network connectivity in Windows, it wasn't enough to uninstall VirtualBox. It was also necessary to trick Windows 8 into updating its drivers.

 

Do you have any references on that?

 

http://www.eightforums.com/virtualization/27292-windows-8-1-virtualbox-2.html
https://forums.virtualbox.org/viewtopic.php?f=6&t=48452

I'm not claiming that there's a solution here. But it might be worth exploring.

 

These are some great ideas. btw - you can trust TrueCrypt 6.3a completely with respect to containing the hidden marks. I am most familiar with the 6.3a code and at one point was running modified code on several Vista machines. Its not the easiest to compile but its not rocket science either. With Vista you could self sign the modified TC exe and blow past the obstacles to install it quite easily. I did that to expressly unlock the hidden OS so that I could write to any medium and use my own discretion about "read only". The reason I am mentioning this is because a look at the normal public code would quickly demonstrate to you why and how the hidden OS totally locked down any "marks" to outside of the partition. Exceptions in the code allow for writes to totally encrypted hidden volumes only and only upon device based encrypted partitions. Its solid you can believe in it. I say that for 6.3a as I have not, nor do I use 7.X, because I haven't looked under its "hood".

Intel PRO/1000 is what pfsense uses on my machine. It immediately finds everything. Guys, I am reading daily and eventually I'll get there. Thank you for the patience and frankly my rambling posts. LOL!