Solved Need help migrating Linux routing commands to FreeBSD

willbprog127

willbprog127

Greetings!

On Linux, I am using a SSH tunnel between my machine and a remote machine. This is an actual tunnel, using the 'tun5' device / interface, not just port-forwarding. This allows me to contact any machine on the remote machine's network, SSH in, VNC in or whatever I need. For routing on my local machine, I use the 'LocalCommand' option in my ~/.ssh/config to run the following script:

Bash: 
# Linux version #

ip addr add 10.10.10.2/32 peer 10.10.10.10 dev tun5
ip link set up tun5

route add -net 10.10.10.0 netmask 255.255.255.0 dev tun5
route add -net 192.168.58.0/24 dev tun5

I have now been trying to get this migrated to FreeBSD, but I am unable to ping the remote machine or any other machines on its network. This is what I have so far (on FreeBSD 12.2 - amd64):

Bash: 
# FreeBSD version #

ifconfig tun5 10.10.10.2 10.10.10.10 add
ifconfig tun5 up

route add -net 10.10.10.0 10.10.10.2 -ifp tun5
route add -net 192.168.58.0 10.10.10.2 -ifp tun5

As mentioned, I cannot contact *anything* over the 'tun5' tunnel. I am not receiving any error messages when the above setup script runs. Can anyone assist me in getting this routing correct on my (FreeBSD) side?

Here is the relevant part of my ~/.ssh/config file:

INI: 
Host sshvpn
   Hostname (remote machine's IP)
   Port (non-standard port)
   User root   # necessary to make tunnel device
   IdentityFile /home/me/.ssh/id_sshvpn
   PreferredAuthentications publickey
   PermitLocalCommand yes
   LocalCommand /home/me/bin/setup-ssh-vpn
   RemoteCommand /root/scripts/setup-ssh-vpn
   Tunnel point-to-point
   TunnelDevice 5:5

Here's the output from netstat -4rn:

Code: 
$ netstat -4rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.0.1        UGS         re0
10.10.10.0/24      10.10.10.2         UGS        tun5
10.10.10.2         link#3             UHS         lo0
10.10.10.10        link#3             UH         tun5
127.0.0.1          link#2             UH          lo0
192.168.0.0/24     link#1             U           re0
192.168.0.100      link#1             UHS         lo0
192.168.58.0/24    10.10.10.2         UGS        tun5

Here's what ifconfig says:

Code: 
$ ifconfig
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
    ether b0:6e:bf:c5:3f:83
    inet 192.168.0.100 netmask 0xffffff00 broadcast 192.168.0.255
    inet6 fe80::b26e:bfff:fec5:3f83%re0 prefixlen 64 scopeid 0x1
    inet6 2600:6c55:7600:9c3:b26e:bfff:fec5:3f83 prefixlen 64 autoconf
    media: Ethernet autoselect (100baseTX <full-duplex>)
    status: active
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
    inet 127.0.0.1 netmask 0xff000000
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
tun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
    options=80000<LINKSTATE>
    inet6 fe80::b26e:bfff:fec5:3f83%tun5 prefixlen 64 scopeid 0x3
    inet 10.10.10.2 --> 10.10.10.10 netmask 0xff000000
    groups: tun
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    Opened by PID 61315

Thank you in advance! :)
 
Run tcpdump(1) on the tun5 interface and see if there is anything getting sent to it. At quick glance your routes look fine. If you do see packets going in but nothing being returned check the routing on the other end of the tunnel.

Code: 
ifconfig tun5 10.10.10.2 10.10.10.10 add
Add subnet masks here. Or the system is going to assume 10. is a class A network (/8). You typically use /30 for point-to-point connections.

Code: 
route add -net 10.10.10.0 10.10.10.2 -ifp tun5
route add -net 192.168.58.0 10.10.10.2 -ifp tun5
No need for the 10.10.10.0 route, it's a directly connected network (it's attached to tun5) so the route is already implicitly set.
No need for the -ifp option either, the system knows the 10.10.10.2 IP address is attached to tun5, no need to explicitly state this. And again, add subnet masks to avoid ambiguity.
Code: 
route add -net 192.168.58.0/24 10.10.10.2
 
SirDice said:
Run tcpdump(1) on the tun5 interface and see if there is anything getting sent to it. At quick glance your routes look fine. If you do see packets going in but nothing being returned check the routing on the other end of the tunnel.

Code: 
ifconfig tun5 10.10.10.2 10.10.10.10 add
Add subnet masks here. Or the system is going to assume 10. is a class A network (/8). You typically use /30 for point-to-point connections.

Code: 
route add -net 10.10.10.0 10.10.10.2 -ifp tun5
route add -net 192.168.58.0 10.10.10.2 -ifp tun5
No need for the 10.10.10.0 route, it's a directly connected network (it's attached to tun5) so the route is already implicitly set.
No need for the -ifp option either, the system knows the 10.10.10.2 IP address is attached to tun5, no need to explicitly state this. And again, add subnet masks to avoid ambiguity.
Code: 
route add -net 192.168.58.0/24 10.10.10.2
Click to expand...
Thanks for the advice -- I appreciate it! :)

I tried tcpdump but did not see any traffic going through the tunnel. I know the routing works fine on the remote side because this setup works great on Linux. I want it to work on FreeBSD as well, so I'll keep plugging along and see what can be done.

Edit: I did do the corrections you suggested but I'm still not getting anything through the tunnel. I'm starting to think it may not be possible with FreeBSD. :( I *knew* tunneling through SSH was too good to be true!

Thanks again!
 
After wrestling with this for a few days now, I'm seeing more information now. Quick recap:

Remote IP of tun5: 10.10.10.10
Local IP of tun5: 10.10.10.2

Using tcpdump, I see this locally when trying to ping 10.10.10.10 from FreeBSD:
Code: 
11:20:25.884526 IP 10.10.10.2 > 192.168.58.207: ICMP echo request, id 54511, seq 109, length 64
11:20:26.885377 IP 10.10.10.2 > 192.168.58.207: ICMP echo request, id 54511, seq 110, length 64
11:20:27.902917 IP 10.10.10.2 > 192.168.58.207: ICMP echo request, id 54511, seq 111, length 64
So basically only seeing it go out but not coming back. On the remote server, where 10.10.10.10 lives, I get this:
Code: 
11:49:11.146271 IP 10.10.10.2 > 192.168.58.207: ICMP echo request, id 44035, seq 18, length 64
11:49:11.146330 IP 192.168.58.207 > 10.10.10.2: ICMP echo reply, id 44035, seq 18, length 64

The remote machine is seeing my ping and replying to it, but the traffic is not available from my local 10.10.10.2. Yes, I've set up routing and no, it still doesn't work. I even tried enabling 'gateway' in my /etc/rc.conf and trying pf to force things, but I still can't get anything from tun5's 10.10.10.2 address. Any suggestions?

Thanks! :)
 
Well folks, I'll mark this as 'resolved'. I give up on trying to use ssh's built-in tunneling on FreeBSD. I ended up experimenting with the latest sshuttle, installed with pip and found it's actually working better than the built-in ssh tunneling when using it on Linux.

For those curious which sshuttle command I used to replace the above nonsense, it's:
Code: 
sshuttle -e 'ssh -i /home/will/.ssh/id_mycutekey' --disable-ipv6 -r myusername@remotesite.com:43210 0.0.0.0/0
Thanks everyone! :)
 
You must log in or register to reply here.
Back
Top