Forum Replies Created

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
  • misterplow

    I think I misunderstood the (English) meaning of the error message.

    When it said it “cannot be read from a file”, I though it meant “I cannot find the file”.

    I did a little more digging around and found that the openvpn binary (on zeroshell) would have to be built with the “–enable-password-save” option in order to accommodate what I want to do, but that’s not the case so I’ll have to find another way to do what I want.


    (see http://openvpn.net/archive/openvpn-users/2005-01/msg00349.html )

    in reply to: VLAN dhcp #50793

    You can create a network bridge with one interface (the vlan in question) and then the gui will let you be a dhcp client on the bridge interface. This gave me the result I wanted.

    in reply to: Host to LAN VPN Routing #49733

    Does the ” –route-noexec ” option do what you want?

    in reply to: How to stopping named sevice #49541

    “service dns stop” *does* stop named, but if you “ps -ef | grep named” for it a minute or two later you’ll find that it’s running again, so that’s not a permanent fix. This behaviour (for which I’m sure there is a reason/explanation) is what prompted me to think if the ugly hack above (which also it a stretch to call a permanent fix..)

    in reply to: How to stopping named sevice #49538

    It’s an ugly hack, but what you have to do is kill named, and then before it gets launched again restart openvpn (to grab udp/53).

    Does this Post Boot script do what you need?

    /bin/killall named;/etc/init.d/openvpn restart

    Setup your OpenVPN server listening on ucp53 (it will fail to start the first time you save it). After this is created, execute the Post Boot script as above or else reboot your box.

    Does that work?

    in reply to: The database does not up when the server restarts #49304

    If you do a backup of your database (click on the radio button next to your active profile and choose “Backup” or “Backup without Logs”), the actual data is small.

    If this were me, and I had to use the same physical (internal) disk, I would

    1. perform the “Backup without Logs” operation
    2. restore the ZS box to the default configuration and reboot
    3. format the disk as ext3
    4. then use the “Restore Profile” option to upload the DB I backed up to my local PC in step 1.

    If you have a USB key or some other removable storage, you could first format that to ext3, copy your active profile there, then do the format of the internal hard disk and then copy the previously active profile from the USB key disk back to the internal hdd.

    in reply to: How to disconnect select active OpenVPN client(s)? #48764

    You’ll have needed to start the openvpn server process with the –crl-verify option, and then revoke the certificate for that user.

    See related post:

    This will kick/bump all client connections, but everyone except the one whose certificate you’ve revoked will (automatically) get back on.

    in reply to: The database does not up when the server restarts #49298

    Hi – could you answer a couple of questions? I use ZS almost exclusively from CD and have never had a problem, even when the machine’s power plug is pulled suddenly.

    1) Do you have the same problem if you manually shutdown the system (nicely) from the WebGUI’s top page? Or is it only a problem with the power goes out suddenly?

    2) Could you send a screenshot (or at least the text?) of your Profiles screen? (a screenshot showing what profile is “active” and what kind of disk partition it is on?

    3) Is it possible that you think you are creating a static database but yet aren’t for some reason? (sorry – not trying to insult you; just want to make sure..)

    in reply to: huge problems with revokation of certs #48355

    The way that OpenVPN works is that each time you revoke a certificate it generates/updates a CRL (certificate revocation list) file, against which it checks incoming client connection requests. Even though you may revoke multiple client certificates, the CRL is just one key, against which multiple clients keys can generate a hit/match.

    You can find the crl.pem file that ZS uses at the location of:


    So, if you start the OpenVPN server process with the option of

    --crl-verify /Database/etc/ssl/crl.pem

    It will then reject any certificates that you have revoked.

    The BIG CATCH is that if you delete a user without first revoking the user’s cert, that user/cert will still be able to connect (as you have noticed, which is probably not what you want).

    In the case you forgot to revoke the cert before deleting the user, you’ll have to have access to the cert and private key for the user you mistakenly deleted. If you don’t have access to these two files then you’re probably screwed 😉

    Assuming you DO have the cert/private key of the deleted user, you need to go in and manually swap it in for the cert+key of the “tempuser”

    1. create a new user in the ZS gui (doesn’t have to be the same as the original username)
    2. using an ssh session into your ZS box, do the following:

      root@zeroshell root> mv /Database/etc/ssl/certs/_user.pem /Database/etc/ssl/certs/_user.pem.orig;vi /Database/etc/ssl/certs/_user.pem

      (paste the _user.pem certificate contents and save)

    3. do the same for the key file located in /Database/etc/ssl/certs/_user.pem, this time pasting in the keyfile contents
    4. now go back into the GUI and revoke the certificate for the . This revocation should trigger an automatic restart of the affected openvpn server process as long as you have started it with the –crl-verify option as listed above.
    5. once this is done, you can delete the _user.pem files and then rename the _user.pem.orig back to the original _user.pem if you need to keep this temporary user and/or its information for some reason

    Once again, just be aware that each time you revoke a certificate against an openvpn server instance where it’s been started with the crl-verify option, you will reset that process and thus kick off all clients briefly.

    in reply to: Multiple WAN IP’s #46461

    Cool — glad it worked out.

    Actually, I should clarify my original reply. I made it sound like ZS is not a cool thing — nothing could be further from my opinion.

    Actually, I *could* set up all the virtual hosts (forwarded WAN ports) using the web interface, but because there were so many hosts/statements, it was just easier to cut and paste some text into the startup script area.

    Great job + many thanks, Fulvio!

    in reply to: Multiple WAN IP’s #46459

    This might not be the exact answer you are looking for, but how about approaching the problem in the following manner:

    1) Enable ssh on your ZS box (and access it)
    (or — use the serial port of your ZS machine; same menu interface)

    2) Access the shell prompt and set up what you want using manual “iptables” commands

    3) Once you can do everything with iptables that you want manually, copy/paste all the commands you want (from your ssh session’s history) in the order you want into ZS’s Startup Bash Script (available from the top menu’s setup->startup tab)

    I’m no expert on iptables, but I was able to do what I wanted (VNC access to 10 different clients on the other side of the NATted interface using a different WAN port for each host). The ZS web interface didn’t quite have what I needed, but the linux shell underneath is still just linux, so it can probably do any kind and combination of packet manipulation that you can dream up.

    I got the iptables commands and syntax I wanted by just mimicking what other people posted on howto and other tutorial documents which I found on google.

    in reply to: Port 1194 #46213

    As long as the tcp port you want to use is open/unused, you can change openvpn to use whatever port you want. There is nothing sacred about 1194.

    in reply to: BRIDGING – No Forwarding, am I missing something? #46206

    If you go into the BRIDGE00 (containing eth0+eth1, right?) device on your ZA box, click on the “View” button under Setup | Network | BRIDGE00

    Here you should see all the MAC addresses the bridge is aware of (scroll down for the FORWARDING DATABASE). The first column (port) will have probably a 1 or 2 — this says that the bridge is aware of that MAC address through the physical bridge member 1 (your eth0) or bridge member 2 (your eth1).

    What you probably want to do is verify that you can see the MAC address of the IPCOP’s interface which has an IP address of You should see this on the bridge port 2 (assuming that’s the eth1 interface on your ZS box).

    If the bridge doesn’t see any MAC addresses on the eth1/1 port, then I’d start by directly connecting the IPCOP machine and ZS/eth1 with a cross-over cable. Get the bridge to be aware of L2 addresses before worrying about L3.

    in reply to: Step by step help needed for Lan to Lan #46360

    I might have a couple of ideas/pointers for you, but first can I ask a question to clarify?

    The impression I get is that you want to physically (ie lan-to-lan) join the eth0 network of each box (so . . the “far” ends of the connection), but the two networks are on different subnets.

    Do you have a routing device in the picture somewhere?

    I’ve implemented several instances of client-to-lan and also lan-to-lan, so I hope to be of help to you. Once you get a couple of concepts understood (well), zeroshell is so easy to work with . . almost a work of art!

    Don’t give up on zs just yet.

Viewing 14 posts - 1 through 14 (of 14 total)