This might be a routing question, I'm not really sure...

jschmidt3786

jschmidt3786

I'm trying to emulate some functionality from a previous linux-based OpenVPN solution onto a new FreeBSD-based OpenVPN solution with different IP ranges.

Old VPN network: 10.0.0.0/8 (there are lots of smaller customer ranges within for isolation)
New VPN network: 172.29.0.0/16 (ditto)

Clients (upwards of ~4k customer appliances) periodically connect to an FTP server also running on the old VPN server at 10.8.0.1.

Once I migrate the clients from old to new, I'd like (ok, "need") them to still hit "ftp://10.8.0.1/" (the URL, not the old server) from the new VPN's range. Since they are appliances and not our property, and I can't really change or update them, I'm stuck w/ the hardcoded URL.

I have a new dedicated ftpd host (VNET jail) connected to the new VPN that has an additional loopback created with a 10.8.0.1 IP.
I've turned on forwarding (gateway_enable) and added a static route to another test client host (route add -net 10.8.0.0/24 <VPN IP of dedicated client running ftpd>).

I can ftp to the dedicated host's VPN IP but not 10.8.0.1.
I'm guessing that using a loopback might be the issue?

edit: I tried w/ a tap interface as well, same result.

edit2: I also tried with 10.8.0.1/24 as an alias IP on tun0; no go.
 
Have the new OpenVPN server (serving 172.29.0.0/16 addresses) push a route to the clients;

Code: 
push "route 10.8.0.1 255.255.255.255"
In this case it's probably a good idea to only route the exact address. But you do need to make sure the route back to the VPN client addresses is correct. For some reason people always forget packets need to know their way back.
 
ok, thanks, I'll try that, but I thought that I accomplished the equivalent by doing this on the the test client:
# route add 10.8.0.0/24 172.29.171.1
Click to expand...
I'd definitely prefer to just route that one IP, though, so will change that.
my routing table on that client looks like this:
Code: 
# netstat -4rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            172.30.42.1        UGS        net0
10.8.0.0/24        172.29.171.1       UGS        tun0
10.99.0.0/24       link#7             U      vm-priva
10.99.0.1          link#2             UHS         lo0
100.69.0.0/24      link#8             U           hw0
100.69.0.18        link#2             UHS         lo0
127.0.0.1          link#2             UH          lo0
172.29.1.128/26    172.29.171.1       UGS        tun0
172.29.1.192/26    172.29.171.1       UGS        tun0
172.29.64.0/18     172.29.171.1       UGS        tun0
172.29.128.0/18    172.29.171.1       UGS        tun0
172.29.171.0/26    link#9             U          tun0
172.29.171.3       link#2             UHS         lo0
172.29.192.0/20    172.29.171.1       UGS        tun0
172.29.208.0/21    172.29.171.1       UGS        tun0
172.29.216.0/21    172.29.171.1       UGS        tun0
172.29.224.0/21    172.29.171.1       UGS        tun0
172.29.232.0/21    172.29.171.1       UGS        tun0
172.30.42.0/25     link#4             U          net0
172.30.42.6        link#2             UHS         lo0
 
jschmidt3786 said:
but I thought that I accomplished the equivalent by doing this on the the test client:
Click to expand...
Yes. Same thing, just automatically done by OpenVPN and a lot stricter.

jschmidt3786 said:
my routing table on that client looks like this:
Click to expand...
That's fine. You could check with tcpdump(1) on the FTP host to see if you can see the connection coming in. You should see at least the SYN from the VPN client to the 10.8.0.1 address. And you'll be able to see the SYN/ACK being sent in return. But the bigger question is, where is the FTP host sending those responses back to? Look at the routing table of the FTP host.
 
I can ping (and ftp) to the openvpn's IP on tun0 but not to 10.8.0.1, no matter which of the three ways I've tried to configure it:
  • lo1
  • a new tap if
  • IP alias on tun0
is there a preferred method to attach this IP?
tcpdump is silent while listening on the server's tun0 interface and I try to hit 10.8.0.1 from the client.
the server's routes look ok, I think. the server looks like so (client is at 172.29.171.3):
# ifconfig tun0
tun0: flags=8043<UP,BROADCAST,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet 172.29.171.8 netmask 0xffffffc0 broadcast 172.29.171.63
inet 10.8.0.1 netmask 0xffffffff broadcast 10.8.0.1
groups: tun
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Opened by PID 53853
# route get 172.29.171.3
route to: 172.29.171.3
destination: 172.29.171.0
mask: 255.255.255.192
fib: 0
interface: tun0
flags: <UP,DONE,PINNED>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 1500 1 0
Click to expand...
 
Don't assign the 10.8.0.1 address to anything else, it's the IP address of the FTP host and should only be set there, nowhere else. Speaking of the FTP host. you said it is a VNET jail? How and where is this configured? How's that jail set up?
 
Sorry, I guess I should have been more clear - 10.8.0.1 is only set on the ftp host, but my question was to which interface to assign it to { lo1, alias to tun, alias to vnet0, a new tap, or ??).
The server is a VNET jail set up via bastille (epair), and is a pretty basic install of 13.3-RELEASE, it's only running as an openvpn client and an ftp server. The physical host has a few other VNET jails for hosting dns, web, etc., but nothing else related to the VPN. The VPN server is hosted in AWS (both the old new VPNs are ec2 instances).
For clarity, my two test hosts are:
  • ftpd test server on the VPN at 172.29.171.8, and aliasing/assigning 10.8.0.1 various ways
  • test client (also 13.3-RELEASE) at 172.29.171.3
The test client can get to 172.29.171.8, but not 10.8.0.1 (ping, traceroute, ftp). The route was manually added onto the client for now, I'll definitely roll that into the VPN server's push list once I have this working.

ftp server:
Code: 
vnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8<VLAN_MTU>
        ether 0e:20:9e:11:1f:88
        hwaddr 02:62:05:da:b9:0b
        inet 172.16.3.144 netmask 0xfffffe00 broadcast 172.16.3.255
        inet 10.8.0.1 netmask 0xffffffff broadcast 10.8.0.1
        groups: epair
        media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
tun0: flags=8043<UP,BROADCAST,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet 172.29.171.8 netmask 0xffffffc0 broadcast 172.29.171.63
        groups: tun
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        Opened by PID 96846
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            172.16.2.1         UGS       vnet0
10.8.0.1           link#23            UH          lo0
127.0.0.1          link#33            UH          lo0
172.16.2.0/23      link#23            U         vnet0
172.16.3.144       link#23            UHS         lo0
172.29.1.128/26    172.29.171.1       UGS        tun0
172.29.1.192/26    172.29.171.1       UGS        tun0
172.29.64.0/18     172.29.171.1       UGS        tun0
172.29.128.0/18    172.29.171.1       UGS        tun0
172.29.171.0/26    link#35            U          tun0
172.29.171.8       link#35            UHS         lo0
172.29.192.0/20    172.29.171.1       UGS        tun0
172.29.208.0/21    172.29.171.1       UGS        tun0
172.29.216.0/21    172.29.171.1       UGS        tun0
172.29.224.0/21    172.29.171.1       UGS        tun0
172.29.232.0/21    172.29.171.1       UGS        tun0

USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
root     ftpd       6547  7  tcp4   *:21                  *:*
root     openvpn    96846 5  udp4   *:55181               *:*
test client:
Code: 
lan0: flags=8963<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4e520bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
        ether 50:9a:4c:0b:47:cd
        inet 172.16.0.42 netmask 255.255.254.0 broadcast 172.16.1.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
tun0: flags=8043<UP,BROADCAST,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet 172.29.171.3 netmask 255.255.255.192 broadcast 172.29.171.63
        groups: tun
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        Opened by PID 22683
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            172.16.0.1         UGS        lan0
10.8.0.1           172.29.171.8       UGHS       tun0
127.0.0.1          link#2             UHS         lo0
172.16.0.0/23      link#1             U          lan0
172.16.0.42        link#1             UHS         lo0
172.16.2.0/23      172.16.0.1         UGS        lan0
172.29.1.128/26    172.29.171.1       UGS        tun0
172.29.1.192/26    172.29.171.1       UGS        tun0
172.29.64.0/18     172.29.171.1       UGS        tun0
172.29.128.0/18    172.29.171.1       UGS        tun0
172.29.171.0/26    link#5             U          tun0
172.29.171.3       link#5             UHS         lo0
172.29.171.8       172.29.171.1       UGHS       tun0
172.29.192.0/20    172.29.171.1       UGS        tun0
172.29.208.0/21    172.29.171.1       UGS        tun0
172.29.216.0/21    172.29.171.1       UGS        tun0
172.29.224.0/21    172.29.171.1       UGS        tun0
172.29.232.0/21    172.29.171.1       UGS        tun0
 
You must log in or register to reply here.
Back
Top