David DeSimone wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Vince <[EMAIL PROTECTED]> wrote:
The main reason to use IPSEC tunnel mode and avoid GIF is that such
a config is interoperable with other IPSEC implementations, and thus
is much more useful in the real world.
OK that said, how do you create a network to network tunnel based VPN
without using the gif or gre devices?
Ok, here's a typical setup that I've used.
Suppose you have two gateways:
Gateway 1 IP = 1.2.3.4
Networks behind it:
192.168.1.0/24
192.168.2.0/24
Most of the examples you'll find will teach you to use IPSEC in
Transport mode. But Transport mode is only used for one endpoint to
talk to another endpoint. What you want here (and what other gateways
like Cisco will implement) is Tunnel mode, where the traffic is
encapsulated rather than merely encrypted.
- --
David DeSimone == Network Admin == [EMAIL PROTECTED]
OK that is a great guide and should be placed in the handbook, maybe
over top of the old one or under a title "Standard VPN"
I copied and pasted most of it and replaced those IPs with mine, but am
still having problems.
After reloading ipsec and racoon I tried to do a traceroute from a
client behind the local gateway to a client behind the remote gateway,
it went off and did a typical traceroute through the gateway out over
the Internet like a regular traceroute, completely being missed by the
kernel/ipsec rules, nothing stopped it or tried to tunnel it or trigger
racoon IKE activity.
I tried putting 'require' in my ipsec rules, didn't change anything.
Did you have any special routes to tell the ipsec/kernel to start
encrypting the traffic?
Are you using FAST_IPSEC or the other IPsec? If so I will have to change.
Which version of FreeBSD are you using?
I need to try and isolate what is different.
Its Fast_IPSEC in my kernel, it is a AMD64 server, I remember AMD64
would instantly trigger a kernel panic with FAST_IPSEC in the past, but
I am assuming it works now.
I have actually managed to trigger a full phase 1 and 2 successful
connection activity if I use the older style gif/gre and on top use a
IPsec gateway to gateway tunnel rule (on top of the regular internal
network ipsec rules) and with the special gif/gre routes most examples
on the net say to use.
Having a gateway to gateway tunnel rule was the only thing that finally
ever triggered racoon and IPSec activity which is pretty weird, and is
double to triple different compared to your example because I needed
gif/gre and routes to trigger racoon/ipsec to start working.
#spdadd 1.2.3.4/32 5.6.7.8/32 any -P out ipsec
esp/tunnel/1.2.3.4-5.6.7.8/require ;
#spdadd 5.6.7.8/32 1.2.3.4/32 any -P in ipsec
esp/tunnel/5.6.7.8-1.2.3.4/require ;
I need to have it all working under the standard way out you have laid
out, like I said my ipsec is in the kernel and fully loaded, but with
your example rules it behaves as if its not there at all.
Mike
sysctl -a | grep ipsec
ipsecpolicy 34 9K - 11913 256
ipsecrequest 4 1K - 181 256
ipsec-misc 0 0K - 258 32,64
ipsec-saq 0 0K - 167 128
ipsec-reg 3 1K - 153 32
net.inet.ipsec.def_policy: 1
net.inet.ipsec.esp_trans_deflev: 1
net.inet.ipsec.esp_net_deflev: 1
net.inet.ipsec.ah_trans_deflev: 1
net.inet.ipsec.ah_net_deflev: 1
net.inet.ipsec.ah_cleartos: 1
net.inet.ipsec.ah_offsetmask: 0
net.inet.ipsec.dfbit: 0
net.inet.ipsec.ecn: 0
net.inet.ipsec.debug: 0
net.inet.ipsec.esp_randpad: -1
net.inet.ipsec.crypto_support: 0
net.inet6.ipsec6.def_policy: 1
net.inet6.ipsec6.esp_trans_deflev: 1
net.inet6.ipsec6.esp_net_deflev: 1
net.inet6.ipsec6.ah_trans_deflev: 1
net.inet6.ipsec6.ah_net_deflev: 1
net.inet6.ipsec6.ecn: 0
net.inet6.ipsec6.debug: 0
net.inet6.ipsec6.esp_randpad: -1
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
