SRX

HI,

I have several remote subnets that i need to access. I heard that we have to use polices based.

So let i followed the juniper tool 

All my peers are up, Phase 1 and 2 okay but i'm unable to access, ping or whatever to these subnets ??? crazy right?

The flow looks okay:

Session ID: 7794, Policy name: trust-to-untrust/4, State: Active, Timeout: 4
  In: local.0.20/1558 --> remote.18.10/512;icmp, If: reth1.0
  Out: remote.18.10/512 --> public.143.2/57068;icmp, If: reth0.0

Session ID: 16584, Policy name: vpn-trust-remote/26, State: Active, Timeout: 32
  In: local.0.20/137 --> remote.2.1/137;udp, If: reth1.0
  Out: remote.2.1/137 --> public.143.2/17934;udp, If: reth0.0

Did I miss something? The third party is an astaro.

Does the third party have routes back to you?

Hi,

Before, I set up via routed based. It works fine with the third party for one remote subnet (remote.0.0)

According to the topology attached:

From astaro: to access to the vpn client (from remote.0.0), static route is used. Now from local.0.0 (SRX network), we need to access to vpn client (X.x.0.0/14, X.y.0.0/16, Z.w.x.0/24)

So I have added vpn client subnets to astaro party.

SRX:

- I declare all these subnets (remote.0.0 and vpn client subnets) in the untrust zone

- create adequate policies from and to.

- create adequate ike, ipsec (same security as before but without bind-interface, proxy-id and so)

All SA are okay but no way that I can access from local.0.0. I can even not access to remote.0.0 anymore.

Attachment(s)

vpn_srx_astaro.pdf   97 KB 1 version

"show log kmd" can show you errors that may occur during VPN establishment. You mentioned that you no longer manually define proxy-id. That is as it should be; it also means the remote side has to have a similar policy-based method of dynamically deriving the phase 2 proxy-id for this to work.

If that doesn't help, use traceoptions in "security flow" and filter for the traffic you want to see.

From what you showed us, I can't make out whether your traffic actually entered the VPN tunnel, or whether it just goes out the Untrust interface unencrypted.

Also keep in mind that NAT and policy-based VPNs do not mix:

- You cannot NAT the traffic through the VPN

- If a host reachable through the VPN is static-NATed to Untrust, that host will not be able to receive packets through the VPN

Hi,

Since the SAs show up, there was nothing on kmd log.

I use NAT for some servers for untrust but not between our subnets.

According to KB15745:

The following are reasons why you implement route-based VPN:
- Source or destination NAT (NAT-src or NAT-dst) needs to occur as traffic travels through the VPN.
- There are overlapping subnets or IP addresses between the two LANs.
- Hub-and-spoke VPN topology is used in the network.
- Primary and backup VPN are required.
- A dynamic routing protocol (for example, OSPF, RIP, or BGP) is running across the VPN.
- Multiple subnets or networks at the remote site across the VPN need to be accessed.

I need the last one !

The following are reasons why you implement policy-based VPN:

- The remote VPN device is a non-Juniper device.
- Only one subnet or one network at the remote site across the VPN needs to be accessed.

I need the first one !

Now, how can we mix both? :S

For this case, we need (via routed based vpn) for each subnet:

- create a secure tunnel

- create a vpn

- allow the secure tunnel in the remote zone.

- allow access via policies.

And then it works !

Hello PowerRanger, 

---

@PowerRanger wrote:

 

For this case, we need (via routed based vpn) for each subnet:

 

- create a secure tunnel

- create a vpn

- allow the secure tunnel in the remote zone.

- allow access via policies.

 

And then it works !

 

---

How have you done the routing?

If you send a packet from subnet A it has to be routed to st.A and if it comes from subnet B it has to go through st.B.

So you needed source based routing, didn't you?

- Steffen