OpenVPN and 1.0-BETA1
-
I must just be totally losing it. I'm sure I remember seeing somewhere on the site how to build an arbitrary-sized pfsense embedded image from the full install, and for the life of me I can't recall where. I have a 64MB flash for the WRAP, and 512MB for the soekris (I thought I would be able to install packages and have logs write out over NFS…oops)
Point me in the right direction? ???
-
Maybe this will help: http://wiki.pfsense.com/wikka.php?wakka=FlashHowTo
Also, you can edit /etc/platform and change it to pfSense and it will convert to a full install. However I haven't tested either of these lately.
-
No, unfortunately that wasn't what I was talking about. That's presuming you already have a flash image, adn want to resize it. What you gave us (I presume?) is a cd iso. What I need is the instructions to go from cd iso to flash. I'm starting to wonder if it was't something like "install to a hard drive, dd to a file, then resize that file…."
-
What I gave was a full update for a already full install.
I'll create an embedded image soon and pop it in that directory.
-
Well, today's the day to be loading up the firewalls, so if you can post that embedded image that would be great. :)
The production box has no cd-rom drive, so I'm imagining the process for installation is to plug in a cd-rom drive, install 1.0-BETA1, then somehow apply the tgz that you posted here? (Don't suppose it's as simply as uploading that from the web interface, or tar xvzf after sftp'ing it to the firewall?)
These boxes will go into "production" this week. Oddly enough, these are development boxes, so having beta software isn't a big deal, however all basic firewalling functions MUST be stable enough that I can administer them 99% remote. These are only 20 minutes away instead of 3 hours, and I do have remote vnc and serial console capabilities, but downtime would be frowned upon, as it holds up the developers. planned downtime however (guys, I need to reboot the firewall in a half hour, down for 5 mins) is completely acceptable. I'm thinking if OpenVPN and opt interfaces are all that are at stake here, we should be fine on this, right?
-
Grrrrr…..
I have this hard drive system from Hacom. They bury the ide header on the main board, so I had to tear it apart to get to it to plug in the cd-rom. There's nothing available to power the cd-rom drive, so I had to crack open an external USB enclosure and use its power supply for the cd drive.
I boot up, go into setup, make sure usb keyboard is enabled (which it is, as I'm able to navigate the menus), but as soon as the freebsd menu comes up, I lose usb keyboard, which of course prevents me from choosing option 7, which is....
Boot FreeBSD with USB Keyboard.
D'oh. This is a paradox if I've ever seen one. There is a ps2 keyboard port header on the mainboard, but they didn't ship it with the adapter, which means I'll be spending my day hacking together an adapter. :( This sucks guys...is there a way to have usb keyboard enabled by default during boot?
-
Okay, just spoke to a guy over at Hacom. He's confused that usb keyboard isn't working, and added that he noticed in the last release that the ability to boot embedded from usb flash drive no long works. So…do we need to tweak /boot in general here? His "recommended" installation method was to use embedded from flash drive or usb cdrom to install so you don't have the tear the system down like I'm doing. That won't work. In the interim, he's going to ship me a ps2 keyboard header, but suggested I attempt to connect to a serial console and run the install from there, so I shall.
This is probably wiki-worthy material. I'll try to get by there today and add this.
-
Well, that failed miserably.
I tried 8n1, 2400, 9600, and 19200. Nothing. :\
So…I'm completely screwed for a few days until the pin header arrives, unless I go buy a female ps2 port and do some hacking. :\
-
Just so we're clear, I did try the suggetions in the wiki, but those are for FreeBSD 5.x, and we're at 6.x. The ability to press a key to do anything is not available. I've found the appropriate switches in /boot/defaults/loader.conf, and those should be added and changed in /boot/loader.conf. Here's what I'mt thinking:
Set us up with two console options prior to boot loader getting ahold of things.
console="vidconsole,comconsole"
Use multiple consoles. (Only good prior to the boot loader grabbing hold, long enough to enable USB Keyboard if desired).
boot_multicons="1"
Load the USB subsystem
usb_load="yes"
Enable USB Keyboards
ukbd_load="YES"
Enable Mass Storage (keychain drives, usb cd-rom drives, etc)
umass_load="YES"
The setup above would work particularly well for full installs and cd/floppy installs. When you run the installation to hard drive, you could set it back to normal or present the user an option, but getting out of the gate this would make more sense, wouldn't it? Vidconsole will still be the default after the beastie menu, but at least to that point you can manually enable usb keyboard. If the desire is to keep the cd install vga, only, then the loading the usb subsystem, keyboard, and mass storage would be sufficient.
-
Okay, I'm a dirty cheater. I loaded the iso up in a hex editor, hunted down the usb_load="NO", ukbd_load="NO", and umass_load="NO", changed them to "YES", and saved it, burned it.
The outcome is suprising. I get no keyboard control at the "beastie" menu (Now FreeBSD menu), nor when I get a prompt. I actually have to unplug the keyboard, plug it back in, then I get keyboard control, which is awesome, except that it won't let you install since everything throws crc errors now. :P
So…yeah. :D I'm still screwed.
-
Booooo, I'm a moron.
Okay, this is still a problem for remote management of the firewall should network be down (I have a remote access vnc-kvm), but I should be able to install. All you have to do is unplug hte keyboard and re-plug it, even with the standard distro, no modifications required. Why the unplug-plug is required, I have no idea.
That said, now it won't install to my hard drive, complaining about "non-standard geometry". Bleh. dd if=/dev/zero of=/dev/ad2 should fix that up quite nicely. Just waiting for the command to complete (expecting it to hit eof on the ad2…)
-
Please try the following steps. I had similiar problems when setting up a nexcom 1041c:
http://www.mail-archive.com/support@pfsense.com/msg03811.htmlMaybe the hacom box is similiar here (I as well mentioned the replug of the USB Keyboard there some time ago) ;)
-
Actually, I found the issue, and I'm not partcularly happy about it.
Bios I set to LBA, first thing I tried.
Then I serached here, found that you'd mentioned manually setting a low PIO mode, so I forced PIO mode 0. Nothing.
I finally, out of desperation, was going jumper by jumper on the mainboard, and noticed that there was a "cock-eyed" jumper on the mainboard next to the ide interfaces. ???
It seems this jumper manually forces ata33 vs ata 66/100. The manual isn't very clear on which it was set to before. Now I've re-seated that jumper so that it shorts the pins, and now I get the error that I have an ultra ata drive plugged into a non-ultra-ata cable, but it boots and installs.
Grrr….infuriating. The BIOS makes you think it is all soft controlled, when in reality it's on the mainboard. Go fig.
DEFINITELY needs a place in the wiki.
-
yeah, just copy and paste the nexcom additions too please :-)
-
Wiki'ed. Didn't do the nexcom stuff. Try to get to it later
http://wiki.pfsense.com/wikka.php?wakka=Hacom
Okay, now that I'm done hijacking the thread, perhaps I can get back to the business of working on OpenVPN? :P
-
I'm sorry guys, I've had zero time to come back to this. :(
I'm going to make every effort to get back to it next week, but I can't make any promises.
If anyone is up for it, we should get 2 or 3 of us to exchange openvpn connection info so we can add and remove several interfaces for testing. I'm game if anyone wants to PM me.
-
Hi!
Sorry that I didn't have time to do the testing, I've been very busy at work, "business as usual"… :(
(Man, I wish I had one of these jobs that would pay me to work for the open source community!)I have finally got some time to look into this post and do some testing with 1.0BETA2 (The BETA1-OpenVPN build wasn't available any more):
I did a very basic install into two VMWare sessions, and I have tried to test the all the available OpenVPN functionality between those two boxes.
Here are the problems which I have encountered, still TODO's:- openvpn messages not appearing in openvpn log in WebGui but in System log instead
- fix client not restarting when enabling disabled client
- XML error: not well-formed (invalid token) at line 117 when entering client-specific configuration
- fix client not restarting when changing interface configuration/when pf reloads
- XML error: not well-formed (invalid token) at line 117 when trying to configure a CRL
- firewall rules (their interface assignment) get messed up when interface is being added/removed
I hope I'll find some time this weekend to flash my WRAP at home with the new version, since the server part still seems to run without any problems.
So, what to do next?
Should I try and look into the above problems and then post a patch again?Marc
-
So, what to do next?
Should I try and look into the above problems and then post a patch again?Yep, that would be ideal. Or someone else… ;)
-
Apparently, for the OpenVPN VPN to work, you need to have a "pass in on tunX" and a "pass out on tunX" rule. Problem is, the pfSense user rules don't all you to create "pass out" rules.
So, instead of letting the user allow what goes through the tun interfaces, adding "pass out on tunX" and "pass in on tunX" in filter.inc depending on the number of tun interfaces configured sounds reasonable. It'd save us a lot of trouble, simplifying a lot things, I think.
The only drawback of this approach is that the user wouldn't have granulated control over the tun interfaces, but the user can control the access to the VPN using the rules for the interface used to connect to the VPN instead.
Or am I overlooking the issue?
-
We create pass out rules on bridges, too so this would be the solution.
create_firewall_outgoing_rules_to_itself() in /etc/inc/filter.inc contains these items so we simply need to ammend this to include tun rules if OpenVPN is in effect.
Someone want to take this on and submit a patch?