Hi all, I have the following scenario:
A VPN between a FreeBSD box and a CISCO appliance.
The VPN is up and running with this configuration:
the /etc/ipsec.conf looks like this:
the IPs 172.16.16.1 and 10.1.24.4 were provided to only establish the VPN, but my local network is 192.168.3.0/24.
So my question is how to make my LAN 192.168.3.0/24 to access the other VPN side 10.1.24.4.
I have been trying with this:
and
and later tried something like:
port 6506 is the only port open from 10.1.24.4 the one I can access if I do something like
NAT seems to be working using tcpdump -n -e -i gre0 I capture this:
But I still can not connect from my lan 192.168.3.0 to 10.1.24.4.
My kernel is compiled with the following options:
and in /etc/rc.conf
I have also tried with gif interfaces but the same thing happens.
The primary interface em0 as an alias 192.168.3.1 but also for testing I created a vlan with something like this:
Any Idea of how to make NAT works on this case ?
The ideal would be to use a mask of 24 on the tunnel something like 172.16.16.0/24 so later I could simple reach the other side but it the VPN provider can't do that and the only alternative or suggestion from their side is to use NAT.
Any idea help, would be appreciated.
A VPN between a FreeBSD box and a CISCO appliance.
The VPN is up and running with this configuration:
Code:
172.16.16.1 --> 174.126.103.210 --> INTERNET <--- 200.46.161.143 <--- 10.1.24.4
Code:
gre0: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu 1476
tunnel inet 174.126.103.210 --> 200.46.161.143
inet 172.16.16.1 --> 10.1.24.4 netmask 0xffffffff
the /etc/ipsec.conf looks like this:
Code:
spdadd 172.16.16.1 10.1.24.4 any -P out ipsec esp/tunnel/174.126.103.210-200.46.161.143/require;
spdadd 10.1.24.4 172.16.16.1 any -P in ipsec esp/tunnel/200.46.161.143-174.126.103.210/require;
the IPs 172.16.16.1 and 10.1.24.4 were provided to only establish the VPN, but my local network is 192.168.3.0/24.
So my question is how to make my LAN 192.168.3.0/24 to access the other VPN side 10.1.24.4.
I have been trying with this:
Code:
nat on gre0 inet from 192.168.3.1 to 10.1.24.4 -> gre0
and
Code:
binat on gre0 from 192.168.3.1 to 10.1.24.4 -> 172.16.16.1
and later tried something like:
Code:
telnet -s 192.168.3.1 10.1.24.4 6506
port 6506 is the only port open from 10.1.24.4 the one I can access if I do something like
Code:
telnet -s 172.16.16.1 10.1.24.4 6506
NAT seems to be working using tcpdump -n -e -i gre0 I capture this:
Code:
23:55:50.280587 AF IPv4 (2), length 64: 172.16.16.1.50985 > 10.1.24.4.6506: Flags [S], seq 967814124, win 65535, options [mss 1436,nop,wscale
9,sackOK,TS val 134017 ecr 0], length 0
23:55:53.519192 AF IPv4 (2), length 64: 172.16.16.1.50985 > 10.1.24.4.6506: Flags [S], seq 967814124, win 65535, options [mss 1436,nop,wscale
9,sackOK,TS val 134317 ecr 0], length 0
23:55:56.988768 AF IPv4 (2), length 64: 172.16.16.1.50985 > 10.1.24.4.6506: Flags [S], seq 967814124, win 65535, options [mss 1436,nop,wscale
9,sackOK,TS val 134637 ecr 0], length 0
But I still can not connect from my lan 192.168.3.0 to 10.1.24.4.
My kernel is compiled with the following options:
Code:
options IPSEC
options IPSEC_FILTERTUNNEL
options IPSEC_NAT_T
options IPSEC_DEBUG
device crypto
device enc
device gre
and in /etc/rc.conf
Code:
gateway_enable="YES"
I have also tried with gif interfaces but the same thing happens.
The primary interface em0 as an alias 192.168.3.1 but also for testing I created a vlan with something like this:
Code:
vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3<RXCSUM,TXCSUM>
ether 52:54:00:27:23:69
inet 192.168.3.1 netmask 0xffffff00 broadcast 192.168.3.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 1 parent interface: em0
Any Idea of how to make NAT works on this case ?
The ideal would be to use a mask of 24 on the tunnel something like 172.16.16.0/24 so later I could simple reach the other side but it the VPN provider can't do that and the only alternative or suggestion from their side is to use NAT.
Any idea help, would be appreciated.