SRX

Hi

I have setup a VPN using the guide supplied by Amazon for the SRX. All went OK and its showing as connected inthe AWS console. But traffic is not flowing either way. When I try to ping the inside tunnel from the SRX I get no response. I've followed the trouble shooting guide in the below link and all checks out until the ping test where it fails.

http://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/Juniper_Troubleshooting.html

Please see extract from my config of the settings I added. One thing I did notice is that there is no global policy they tell you to set for the VPN do I need this as I thought I would?  How can I trouble shoot further?

    ike {

        proposal ike-prop-vpn-c0e245fn-1 {
            authentication-method pre-shared-keys;
            dh-group group2;
            authentication-algorithm sha1;
            encryption-algorithm aes-128-cbc;
            lifetime-seconds 28800;
        }
        proposal ike-prop-vpn-c0e245fn-2 {
            authentication-method pre-shared-keys;
            dh-group group2;
            authentication-algorithm sha1;
            encryption-algorithm aes-128-cbc;
            lifetime-seconds 28800;

        policy ike-pol-vpn-c0e245fn-1 {
            mode main;
            proposals ike-prop-vpn-c0e245fn-1;
            pre-shared-key ascii-text "dfhsthjrthrthjrtj"; ## SECRET-DATA
        }
        policy ike-pol-vpn-c0e245fn-2 {
            mode main;
            proposals ike-prop-vpn-c0e245fn-2;
            pre-shared-key ascii-text "ytkruktilktkty"; ## SECRET-DATA

        gateway gw-vpn-c0e245fn-1 {
            ike-policy ike-pol-vpn-c0e245fn-1;
            address 34.222.89.23;
            dead-peer-detection {
                interval 10;
                threshold 3;
            }
            no-nat-traversal;
            external-interface reth0.0;
        }
        gateway gw-vpn-c0e245fn-2 {
            ike-policy ike-pol-vpn-c0e245fn-2;
            address 52.212.76.86;
            dead-peer-detection {
                interval 10;
                threshold 3;
            }
            no-nat-traversal;
            external-interface reth0.0;
        }
    }
    ipsec {
        proposal ipsec-prop-vpn-c0e245fn-1 {
            protocol esp;
            authentication-algorithm hmac-sha1-96;
            encryption-algorithm aes-128-cbc;
            lifetime-seconds 3600;
        }
        proposal ipsec-prop-vpn-c0e245fn-2 {
            protocol esp;
            authentication-algorithm hmac-sha1-96;
            encryption-algorithm aes-128-cbc;
            lifetime-seconds 3600;

        policy ipsec-pol-vpn-c0e245fn-1 {
            perfect-forward-secrecy {
                keys group2;
            }
            proposals ipsec-prop-vpn-c0e245fn-1;
        }
        policy ipsec-pol-vpn-c0e245fn-2 {
            perfect-forward-secrecy {
                keys group2;
            }
            proposals ipsec-prop-vpn-c0e245fn-2;
        }
        vpn vpn-c0e245fn-1 {
            bind-interface st0.2;
            df-bit clear;
            ike {
                gateway gw-vpn-c0e245fn-1;
                ipsec-policy ipsec-pol-vpn-c0e245fn-1;
            }
        }
        vpn vpn-c0e245fn-2 {
            bind-interface st0.3;
            df-bit clear;
            ike {
                gateway gw-vpn-c0e245fn-2;
                ipsec-policy ipsec-pol-vpn-c0e245fn-2;
            }
        }
    }
    zones {
        security-zone vpn {
            host-inbound-traffic {
                system-services {
                    https;
                    ssh;
					ping;
                }
                protocols {
                    bgp;
                }
            }
            interfaces {
				st0.2;
                st0.3;
            }
        }
    }
}

    st0 {
        unit 2 {
            family inet {
                mtu 1436;
                address 169.241.11.123/30;
            }
        }
        unit 3 {
            family inet {
                mtu 1436;
                address 169.241.11.170/30;
            }
        }
    }
}

protocols {
    bgp {
        group ebgp {
            type external;
            neighbor 169.241.11.212 {
                hold-time 30;
                export EXPORT-DEFAULT;
                peer-as 9059;
                local-as 65000;
            }
            neighbor 169.241.11.169 {
                hold-time 30;
                export EXPORT-DEFAULT;
                peer-as 9059;
                local-as 65000;
            }
        }
    }
    l2-learning {
        global-mode switching;
    }
}

The security policy will be needed for transit traffic.  The ping to the tunnel interface is "se;f" traffic and will be permitted by your host inbound services on the zone.

Does the ping work without the size and do not fragment?

Is the st0 interface up/up?

Can you confirm your local st0 interface and the remote tunnel are in the same subnet?

Should I add a policy like below?:

policy vpn-vpn {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                    from-zone [ vpn outside ];
                }
                then {
                    permit;
                }
            }

No Ping does not work without the size and do not fragment.

st0 interface up/up? Yes  

Yes they are in the same subnet.

The policy should not be needed for self to self traffic.

I notice there is a descrepancy in the ip subnetting for the st0.2 interface:

169.241.11.123/30 is the broadcast address.  the two interfaces should be 121 and 122.

I also notice that your BGP nieghbor shows a different subnet so you should confirm which is the one you have on the other side.  169.241.11.212 - also this is the subnet address where the active addresses would be 213 & 214 for the interfaces.

Hi,

Please ignore ips, I put in fake ones they are correct in my setup.

Hello,

Could of thoughts

1. Are you learning any routes from AWS via the BGP neighborship over tunnel?

2. You would need a policy from vpn zone to the zone in which your local subnet resides. I see reth0.0 here is your external interfaces, but I am assuming traffic flow is from vpn to internal zone and vice versa.

Regards,

Vikas

Yes routes are being learned, my SRX is picking up 172..... from my AWS VPC.

So I need a policy like below?

policy vpn-inside {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                    from-zone vpn ;
                    to-zone inside;
                }
                then {
                    permit;
                }
            }

Hi VOIPBunny, 

If the VPN phase 1 (IKE) and Phase 1 (IPSec) are both UP and there are routes pointing to AWS subnet on SRX via st0 interface then you might need the security policies to allow the traffic both ways, 

from-zone VPN to-zone inside {
policy Pol-1 {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}

And , 

from-zone inside to-zone VPN {
policy Pol-2 {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}

You can add specific address book to define the subnets instead of any in my example.