@keithr wrote:
If you have separate routing instances on your SRX boxes, then your gateway / external interfaces will have separate IP addresses, so you won't be configuring your IKE gateways to the same IP address.
On SRX-1 (routing instance A), your IKE gateway will point to the external interface IP of SRX-2 (routing instance A). For SRX-1 (routing instance B), your IKE gateway will point to the external interface IP of SRX-2 (routing instance B). They shouldn't be the same.
If that isn't what you're asking, perhaps post a diagram and a config for us to look at.
Hi all,
After much searching of the message boards and some deep diving into the Junos documentation I was able to solve this issue and get the setup that I needed to work. Details below:
The situation I was attempting to solve wouldn't have different IP addresses as it was using the same ike gateway with two IPSEC vpn's bound to two different st0 units (which would be in two different routing instances). Best example is:
SRX-1 SRX-2
Routing Instance 1
st0.2 10.1.1.1/30 --- | Routing Instance 1
| Default Routing instance |------10.1.1.2/30
| ------30.30.1.254--->INTERNET<---20.3.1.254-----|
st0.36 20.2.2.1/24---| |------20.2.2.2/24
Routining Instance 2 Routining Instance 2
The failed configuration is as follows
interfaces {
st0 {
unit 2 {
family inet {
mtu 1400;
address 10.1.1.1/30;
}
unit 36 {
family inet {
mtu 1400;
address 10.2.2.1/30
}
}
security {
ike {
gateway ATgtwy {
ike-policy ipsec-psk-policy;
address 20.3.1.254;
dead-peer-detection {
interval 10;
threshold 3; }
external-interface ge-0/0/8.0;
}
ipsec {
vpn ATvpn {
bind-interface st0.2;
ike {
gateway ATgtwy;
ipsec-policy nopfs-esp-aes256-sha-policy;
}
establish-tunnels immediately;
}
vpn AT_ESLvpn {
bind-interface st0.36;
ike {
gateway ATgtwy;
idle-time 60;
ipsec-policy nopfs-esp-aes256-sha-policy;
}
establish-tunnels immediately;
}
}
With the above configuration I would have the same situation as the original poster where at any given time only one of the st0 interfaces could successfully send traffic to the other. The root cause of this issue is due to the SPI value being assigned to the to the two VPN's bound to the single gateway. Junos uses a combination of the source IP, destination IP, and service port to create the SPI value for a tunnel. So in the case above, both tunnels would have a SPI value of: (0,0.0.0.0/0, 0.0.0.0/0) creating a non-deterministic way for the traffic to be routed to the correct st0 interface. The solution to the issue was to create a unique SPI for each VPN bound to the gateway, as seen in the config below:
security {
ike {
gateway ATgtwy {
ike-policy ipsec-psk-policy;
address 175.28.239.41;
dead-peer-detection {
interval 10;
threshold 3; }
external-interface ge-0/0/8.0;
}
ipsec {
vpn ATvpn {
bind-interface st0.2;
ike {
gateway ATgtwy;
proxy-identity {
local 10.1.1.1/32;
remote 10.1.1.2/32;
}
ipsec-policy nopfs-esp-aes256-sha-policy;
}
establish-tunnels immediately;
}
vpn AT_ESLvpn {
bind-interface st0.36;
ike {
gateway ATgtwy;
idle-time 60;
proxy-identity {
local 20.1.1.1/32;
remote 20.1.1.2/32;
}
ipsec-policy nopfs-esp-aes256-sha-policy;
}
establish-tunnels immediately;
}
With the configuration above, the SPI value for the two VPNs are different, allowing the Junos device to parse out which tunnel a packet is destined for fixing the issue.
dave
References:
http://kb.juniper.net/InfoCenter/index?page=content&id=KB16008&actp=search&searchid=1273847680110&smlogin=true
http://www.juniper.net/techpubs/software/junos-security/junos-security95/junos-security-swconfig-security/ipsec-vpn-overview.html