|
||||
Here's the gateway side configuration...
Code:
/etc/hostname.tun0 inet 10.0.0.1 255.255.255.252 10.0.0.2 group tun Code:
/etc/hostname.tun1 inet 10.0.0.5 255.255.255.252 10.0.0.6 group tun Code:
/etc/hostname.tun2 inet 10.0.0.9 255.255.255.252 10.0.0.10 group tun Code:
/etc/hostname.tun3 inet 10.0.0.13 255.255.255.252 10.0.0.14 group tun Code:
/etc/ssh/sshd_config # Protocol 2 LoginGraceTime 20 PermitRootLogin yes Banner /etc/ssh/sshd_banner PrintMotd yes UseDNS no MACs hmac-ripemd160,hmac-sha1 ciphers aes256-ctr,aes128-ctr,3des-cbc ListenAddress vpn.mydomain.com:443 ClientAliveInterval 20 ClientAliveCountMax 3 StrictModes yes MaxAuthTries 3 PermitTunnel point-to-point PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys PasswordAuthentication no ChallengeResponseAuthentication no # Subsystem sftp /usr/libexec/sftp-server #
__________________
Never argue with an idiot. They will bring you down to their level and beat you with experience. Last edited by s2scott; 5th May 2008 at 02:47 PM. |
|
||||
/etc/pf.conf fragment...
Code:
# ----- pass in log quick on outside inet proto tcp \ from !<BadSshVpn> to (outside:0) port 443 \ tag SSHVPN flags S/SFRA keep state \ queue(Q5VPN,Q7) \ (max-src-conn-rate 3/120, overload <BadSshVpn> flush global) # pass in log quick on tun inet \ from (tun:peer) to any \ tag TUNPKTS \ keep state # pass out log quick on inside inet \ tagged TUNPKTS keep state # -----
__________________
Never argue with an idiot. They will bring you down to their level and beat you with experience. Last edited by s2scott; 5th May 2008 at 02:54 PM. |
|
||||
The feature of ssh -w (for me) is that,
/S
__________________
Never argue with an idiot. They will bring you down to their level and beat you with experience. Last edited by s2scott; 5th May 2008 at 04:58 PM. |
|
||||
Quote:
But the -w just -- and I mean j-u-s-t -- brings up the ssh encrypted tunnel. How you use the tunnel depends on what you do next. On the CLIENT side... Code:
ifconfig tun0 10.3.0.2 255.255.255.252 10.3.0.1, where .2 is the client and .1 is the gateway tunnel endpoint.
These route commands can be scripted easily and may be built into the hostname.tun0 with the "!" prefix.
__________________
Never argue with an idiot. They will bring you down to their level and beat you with experience. Last edited by s2scott; 6th May 2008 at 02:21 AM. |
|
||||
I'm dredging up this old thread to ask a clarifying question: what happens when your laptop is on the same RFC1918 subnet as the private LAN you're attempting to route to?
e.g.: In your example, s2scott, the destination subnet is 192.168.2/24. But ... what happens if where you're connecting from is in the same or an overlapping subnet? e.g.: connecting from 192.168.2.221? or 192.168.50.100 when the netmask is 255.255.0.0? I ask because I happened to see the IPSec/NAT article just pubbed in the Journal, and thought about address collisions with NAT. Would NAT via the tun(4) device be a possible play? http://undeadly.org/cgi?action=artic...20090127205841 Last edited by jggimi; 29th January 2009 at 08:29 PM. |
|
||||
Having experimented, I have determined it is possible to avoid RFC1918 collisions or interference with any other IPv4 address: Use IPv6 addressing on the tun device instead of IPv4. But unless you also set up a gif(4) tunnel for IPv4, NAT is the only way to ensure no routing problems.
Having played with tunneling ipv4 over ipv6 with gif; I find it easier to set up IPSec. |
|
||||
Quote:
|
|
||||
Problem statement and solution architecture
As I'd stated above, IPSec is easier because one doesn't need to deal with a virtual subnet on the tunnel itself, as we do with SSH. When I tested this, I just used NAT on tun0 -- but this more robust solution, below, is a possibility. I may use BINAT and NAT in combination, if I determine it makes a simpler solution.
I'll be testing this and coming up with sample scripts and config files this week, but I thought I would publish an initial architecture beforehand... just in case I've missed something obvious. And it's easy to miss something; there are six virtual IP subnets in the solution. Problem: Solution: Last edited by jggimi; 3rd February 2009 at 08:21 PM. |
|
||||
I set up the virtual infrastructure last evening, and got it working. 5 QEMU virtual machines with 4 unique vlans.
The first thing I learned was that dhclient will not communicate with tun(4) devices, nor will it operate properly even if the tun device is driven through a bridge(4). I stopped at that point, and will pick it up again either tonight or on the weekend. Last edited by jggimi; 4th February 2009 at 07:32 PM. |
|
||||
Quote:
I usually use 169.254.n.n for the tun address spaces. It is a "reserved" range but will almost never collide. /S
__________________
Never argue with an idiot. They will bring you down to their level and beat you with experience. |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
sysjail alternative | Stellar | OpenBSD General | 7 | 4th September 2009 04:38 PM |
Alternative Architecture Laptops | JMJ_coder | General Hardware | 6 | 7th October 2008 05:05 PM |
Alternative to FoxPro? | michaelrmgreen | Programming | 2 | 18th July 2008 11:40 AM |
iTunes alternative | stukov | Off-Topic | 8 | 14th June 2008 01:55 PM |
There is an alternative way to find a packages? | aleunix | OpenBSD Packages and Ports | 23 | 6th June 2008 07:18 AM |