OpenVPN Bridging Tunnels
-
Is it possible to create bridging tunnels via the Web GUI? I got a site-to-site bridging tunnel going but I had to use the command line to do everything from creating the bridge, setting up the config and the ca keys. I figured if I use the shellcmd in the config.xml, I could do set this to work on reboot but I'd like to be able to use the web GUI. :-\
Also, I've been told you can bridge via the web interface. Where can I find this option?
Besides this, I've enjoyed learning a bit about FreeBSD with this little project. :D Hopefully we can get this power supply in for this pc so I can load it on this SolidLogic 3677.
EDIT Complete re haul of this post since I fixed the major problems I had.
-
Find the bridging option in the web GUI menu Interfaces/LAN
cheers…
-
Um, that's a big NO there.
Take a look over here:
http://docs.pfsense.org
Look at OpenVPN, near the very bottom.
-
I gave up on the web gui. I got a fully functional OpenVPN server with tap0 going now serving tunnels for remote locations and road warriors. The only problem I'm having now is assigning IP addresses. I'm eating up 3 IPs on the range per remote office we connect. I want to do this a bit more efficiently if possible.
I can help anyone with bridged/tap0 tunnels if help is needed.
If anyone has any suggestions on optimizing this setup, let me know:
BTW, I'm using a PC for the main office, a PC for one of the remotes, and a WRAP box with a different flash card for the other remote. They run either snapshot 2/9 or 2/12
-
-
After having this up at the end of work on Friday and leaving it on over the weekend, we've ran into a similar scenario. Like last night, I got a call that the box was down. Once I had it rebooted, I ssh'd in and all was fine. I go to lay down and watch TV with the girlfriend, come back 30-45 minutes later and the box is down again. SSH times out and I can't reach it. When I go to visit the box this morning before work, it's magically pinging out to the Internet with no user intervention. ???
I found this script in the release we're using (snapshot from 2/9/2007) called /etc/ping_hosts.sh. I'm gonna try and set this up to see if I can rectify this to some degree.
-
I found this script in the release we're using (snapshot from 2/9/2007) called /etc/ping_hosts.sh. I'm gonna try and set this up to see if I can rectify this to some degree.
This script is used to automatically establish/keep alive IPSEC Tunnels. It's used if you enter a keepalive IP in the field at the bottom of the IPSEC Tunnel edit screen. Maybe this option would be helpful for OpenVPN Tunnels too?
-
I tried it out with the box hosting the VPNs for us and it works great for just checking to see if the box is up and rebooting if not. We just tested it running it and unplugging the WAN. On the WRAP I tried this on though, the /var/db/hosts file was cleared on reboot. I made something in /usr/local/etc/rc.d recreate it though.
The only problem is that I guess I have the syntax right. For just checking up and down, it works fine though.
Here's the error I get:
PROCESSING 192.168.75.7|4.2.2.2|10|/tmp/shutdown.sh|/tmp/up.sh|999|999
Processing 4.2.2.2
PING 4.2.2.2 (4.2.2.2) from 192.168.75.7: 56 data bytes
64 bytes from 4.2.2.2: icmp_seq=0 ttl=247 time=16.167 ms
64 bytes from 4.2.2.2: icmp_seq=1 ttl=247 time=15.761 ms
64 bytes from 4.2.2.2: icmp_seq=2 ttl=247 time=16.309 ms
64 bytes from 4.2.2.2: icmp_seq=3 ttl=247 time=18.847 ms
64 bytes from 4.2.2.2: icmp_seq=4 ttl=247 time=25.969 ms
64 bytes from 4.2.2.2: icmp_seq=5 ttl=247 time=26.756 ms
64 bytes from 4.2.2.2: icmp_seq=6 ttl=247 time=14.858 ms
64 bytes from 4.2.2.2: icmp_seq=7 ttl=247 time=23.865 ms
64 bytes from 4.2.2.2: icmp_seq=8 ttl=247 time=14.006 ms
64 bytes from 4.2.2.2: icmp_seq=9 ttl=247 time=14.264 ms–- 4.2.2.2 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.006/18.680/26.756/4.708 ms
Checking ping time 4.2.2.2
Ping returned 0
[: 18.664: bad number
Checking wan ping time nan
[: nan: bad numberbut yeah, that script is hella useful for OpenVPN tunnels. Maybe it'll fix the tunnel dying problem we're having