Posts Tagged ‘site-to-site’
One of the best IPsec devices I have worked with so far is Stoke. And when I am saying best I mean it in a sense of compliance, flexibility, stability and performance.
Although it has its minuses, like any device on earth, the pretty SSX-3000 solution I’ve got my hands on knew most of the Remote-Access scenarios I could think of and EAP authentication on top. Besides that, I could do my work undisturbed, while my colleagues were experimenting on their own. Why? Because of the contexts: each one of these “virtual” routers minds its own business, permitting me to play around with my stuff, while the others could work very well, without having to worry about Cristina’s ideas. Now, 240k IPsec tunnels in remote-access with EAP authentication versus Radius and support for digital certificates sounds pretty good if you were to ask me. Mwell…not good enough for the Stoke guys…it seems. So they came up with an even more interesting idea: LAN-to-LAN. Now..hmm..this powerful machine, able of doing so much on RA…could it also be doing site-to-site? So, I’ve contacted my favorite Japanese techie and asked for instructions.
This is the way it works:
Let’s assume there are 2 security gateways, Tokyo (10.1.1.2) and Bucharest (10.1.1.1). Tokyo gateway protects a network (5.1.1.0/24), while in Bucharest we have another network (6.1.1.0/24). Stoke has the concept of “tunnel-enabled interface”, which is a only /32 IP address of an interface type “tunnel”. The following services are not allowed on a tunnel-enabled interface: static IP hosts, ARP, and routing protocols.
So, in our case, let’s assume the tunnel interface for Tokyo is 9.9.9.1/32 and for Bucharest it is 9.9.9.2/32.
As everything on an SSX is done via a context, let’s assume that Tokyo has a context called TB1 and Bucharest has a context called BT1, on which they have this LAN-to-LAN configuration. The configuration on Tokyo would look something like this:
context TB1
interface Tokyo-LAN
arp arpa
ip address 5.1.1.0/24
exit
interface Tokyo-Bucharest
arp arpa
ip address 10.1.1.2/24
exit
interface Tokyo-Tunnel tunnel
ip address 9.9.9.1/32
exit
ipsec policy ikev2 phase1 name si_p1
suite3
gw-authentication psk open_sesame
peer-authentication psk
exit
exit
ipsec policy ikev2 phase2 name si_p2
suite4
exit
exit
exit
tunnel Tokyo-Bucharest-TUN type ipsec protcol ip44 context TB1
enable
ip local 10.1.1.2 remote 10.1.1.1
bind interface Tokyo-Tunnel TB1
ip route 6.1.1.0/24
ip route 9.9.9.2/32
exit
ipsec policy ikev2 phase1 name si_p1
exit
ipsec policy ikev2 phase2 name si_p2
exit
port ethernet 1/1
bind interface Tokyo-LAN TB1
exit
enable
exit
port ethernet 1/0
bind interface Tokyo-Bucharest TB1
exit
service ipsec
enable
exit
While the Bucharest config should be like this:
context BT1
interface Bucharest-LAN
arp arpa
ip address 6.1.1.0/24
exit
interface Bucharest-Tokyo
arp arpa
ip address 10.1.1.1/24
exit
interface Bucharest-Tunnel tunnel
ip address 9.9.9.2/32
exit
ipsec policy ikev2 phase1 name si_p1
suite3
gw-authentication psk open_sesame
peer-authentication psk
exit
exit
ipsec policy ikev2 phase2 name si_p2
suite4
exit
exit
exit
tunnel Bucharest-Tokyo-TUN type ipsec protcol ip44 context BT1
enable
ip local 10.1.1.1 remote 10.1.1.2
bind interface Tokyo-Tunnel TB1
ip route 5.1.1.0/24
ip route 9.9.9.1/32
exit
ipsec policy ikev2 phase1 name si_p1
exit
ipsec policy ikev2 phase2 name si_p2
exit
port ethernet 2/1
bind interface Bucharest-LAN BT1
exit
enable
exit
port ethernet 2/0
bind interface Bucharest-Tokyo BT1
exit
service ipsec
enable
exit
To verify the config, run:
Stoke [TB1]# sh ike-session list
—————————————————————————-
Tags: ipsec, lan-to-lan, passion, site-to-site, SSX-3000, stoke, techie