SRX Services Gateway
Highlighted
SRX Services Gateway

AWS VPN Connects but no traffic

[ Edited ]
‎01-02-2018 02:14 AM

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;
    }
}
7 REPLIES 7
Highlighted
SRX Services Gateway

Re: AWS VPN Connects but no traffic

‎01-02-2018 02:39 AM

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?

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
SRX Services Gateway

Re: AWS VPN Connects but no traffic

‎01-02-2018 03:12 AM

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.

 

Highlighted
SRX Services Gateway

Re: AWS VPN Connects but no traffic

‎01-02-2018 04:23 PM

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.

 

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
SRX Services Gateway

Re: AWS VPN Connects but no traffic

‎01-02-2018 09:28 PM

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

Highlighted
SRX Services Gateway

Re: AWS VPN Connects but no traffic

‎01-03-2018 02:47 AM

Hi,

 

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

Highlighted
SRX Services Gateway

Re: AWS VPN Connects but no traffic

‎01-03-2018 02:51 AM

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;
                }
            }
Highlighted
SRX Services Gateway
Solution
Accepted by topic author VOIPBunny
‎01-04-2018 03:22 AM

Re: AWS VPN Connects but no traffic

‎01-03-2018 06:10 AM

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. 

 

 

Feedback