SRX

Hi all,

I have two SRX3600. They are connected via layer 3 IPSec VPN. Both of them are connected branch routers. Dynamic routing protocol is OSPF.

I want to have the same subnet on two SRX, but certain IPs wouldn't overlap. For example I will have 192.168.1.0/24 subnet on both SRX, but 192.168.1.1/32 host will be only on subnet connected to 1st SRX or 192.168.1.2/32 host will be only on subnet connected to 2nd SRX. Both 192.168.1.1/32 and 192.168.1.2/32 hosts must have connection to each other and must be reachable from branch routers.

How to do?

Thanks

For overlapping subnets communication between two sites you need dual nat (source and desitnation nat on same flow). Eaiset way to achive the goal is to configure static nat (for this you need two addidation private subnets e.g 10.10.10.0/24 for SRX 1 and 11.11.11.0/24 for SRX 2) . Make sure proper routing for private subnets on your core router and both SRX/ NAT configuration is as under:-

+++++++++++++++*******************++++++++++++++++ (for SRX 1)

edit security nat static

set rule-set 1 from zone untrust

set rule-set 1 rule 1 match destination-address 10.10.10.0/24

se rule-set 1 rul1 1 then static nat prefix 192.168.1.0/24

++++++++++++++*******************+++++++++++++++++(For SRX 2)

edit security nat static

set rule-set 1 from zone untrust

set rule-set 1 rule 1 match destination-address 11.11.11.0/24

se rule-set 1 rul1 1 then static nat prefix 192.168.1.0/24

Hi there,

My 2 cents worth...

Whereas NAT is great and cool, one also has to configure DNS to return NATed addresses rather than original IP.

Plus some traffic (i.e. packets with TTL=1) won't pass through routed hops.

So it all really depends on the particular network setup and application mix.

"Transparent mode" SRX may be an option

http://www.juniper.net/techpubs/en_US/junos12.1/information-products/pathway-pages/security/security-layer2-bridging-transparent-mode.pdf 

HTH

Thanks
Alex

Dear aarseniev,

When I use "Transparent mode" between two SRX, how can I provide VPN between them ?

Thanks

I think what you are trying to do is a MPLS  layer 2 stretch ?

are you trying to put hosts from remote location A and host from remote location B in the same subnet? say 192.168.1.0/24?

if so you may want to run a layer 2 circuit between 2 sites. This config is somewhat complex.

it's layer 2 circuit over mpls overGRE over ipsec

SRX has a feature called seletive packet mode. with that you can accomplish it.

The scenario which is described by bc54 can not be implemented on High End SRX, MPLS is supported only on Branch SRX

What you're trying to do is not good practice in network design.  You shouldn't have overlapping subnets within the same contiguous network.

That aside, filthy hacks are a hobby of mine, so I'll make some (ugly) suggestions as to how this might work.

So, the first one that comes to mind (if your hosts support it):

1. Configure the SRX interface that points towards the host as 192.168.1.0/31 and the host itself as 192.168.1.1/31 (255.255.255.254) with a default gateway of 1.0. 

2. At the other end, make the SRX interface 192.168.1.3/31 with the host as 192.168.1.2/31 with a default gateway of 1.3.

3. Re-distribute into OSPF and you're done.

I suspect you probably can't reconfigure the hosts though, or you probably wouldn't be attempting this.  So, filthy hack no.2:

1. Firstly, redistributing the subnets into OSPF is *not* going to work.  Create a static host route (/32) on each SRX for the far-side host and give it the next-hop of your tunnel interface (assuming route-based VPN here.  Another hobby of mine is hating on policy-based VPNs)

2. Enable proxy-arp on the host-facing SRX interface for just the address of the far-side node and you're done.  This should draw traffic towards the SRX as it responds to ARPs on behalf of the far-side device and the static host-route should ensure forwarding.

I'm sure there's a third hack in there somewhere involving routing-instances and route-leaking and proxy-arp, but I'll leave that as an exercise for you to explore if you don't get anywhere with the above two options.

Hope this helps

If only J-Net had a "Mark as Filthy Hack" button....

Dear dfex, thanks for reply.

Before your post I have already tried 2nd option suggested by you - static routes with /32 masks and proxy-arps. Yes, it works, but I think that it wouldn't work for some protocols e.g. VRRP.

On other vendors I can use L2TP but as I know L2TP over IPSec is not supported on SRX devices.

What can I do something like that on SRX3600?

Where is the VRRP in your topology?

Using L2TP would make a bad design even worse.  Stretching a subnet between locations over an IPSEC tunnel is a recipe for disaster.  You'd be better off re-numbering the hosts. 

If on 1st SRX interface IP will be 192.168.1.252 /24, 2nd SRX interface IP will be 192.168.1.253 /24, and virtual gateway will be 192.168.1.254 /24, VRRP will work or not, i.e. multicast packets will go between SRXs?

For layer 2 over layer 3 which design/protocols is best practice on Juniper SRX 3600 ?

Thanks

If you have two SRX3600s in the one location, why not just cluster them?  No need for VRRP at all.

I don't think the DC units (1400,3400,3600,5400,5600) support any L2 over L3 functionality.  The branch units do, however I don't think introducing this functionality is a good answer - really you should probably fix the hosts and their overlapping IPs.

I agree with Ben that it seems like you are looking at overcomplicated solutions and trying to create a data center bridge over an internet VPN.  This would not be a good or stable approach.

Clustering is also the best approach for your two local devices in the DC as it brings lots of advantages over vrrp.

I'd like to back up and ask a background question.  Why do you want these overlapping subnets?

I suspect you may be trying to seutp a DR datacenter at a separate location and that is why you have two locations with the SRX3600.  If this is so, have a look at these Juniper introductions to data center bridging.

http://www.juniper.net/documentation/en_US/learn-about/data-center-bridging.pdf

http://www.youtube.com/watch?v=E6xleeIs5N0&list=PL8175F2244463557F

Dear dfex,

Two SRX3600s are in different locations, connected with 0.5 Gbit/s connection - leased L2 line.

Dear spuluka,

For data center bridging there are needed additional devices (e.g. QFX switches) and high speed connection - 10Gbit/s, 40Gbit/s.

As I understand there are no "good" choice in my case that I can implement.

Thanks

The performance on layer 2 over IPSEC VPN leaves a lot to be desired.  But it is possible if that is your only option.  This is better than trying some type of nat scheme.

Example: Configuring VPLS over GRE with IPSec VPNs

http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/security/software-all/mpls/index.html?topic-63222.html

Dear spuluka,

I can't configure VPLS over GRE with IPSec VPNs on  High End SRX.

MPLS is supported only on Branch SRX:

https://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-srx-jseries-support-reference/jd0e6237.html

Thanks

I'm confused - if the SRXs are in different locations and you have no L2 link between them, how is VRRP going to work?

Yes, Ben, I'm about that - with static routes we will have simulate same subnet in different locations, but it will be not clear L2, as it is in subnet.

You probably can hack together routing so that other subnets access some hosts in the remote data center via the tunnel and others locally.  And it would be ugly.

But what you really can't do is convince a local host in that split subnet to access a remote host livinig in the same subnet with the subnet address.  They will just arp for a local answer.  And this is typically the requirement for the failover scenario at the application level.

If the application does NOT require that the failover server be addressed into the same subnet, then put the remote servers into a new subnet and use standard routing without any of these nat and special routes.

If the issue is getting users to access the secondary data center during a failure you might consider using DNS.  Point applications to a dns name with a very short ttl, like 5 minutes.  If a failure occurs change the dns entry to point to the new data center server and the users get there after a short delay.

---

@spuluka wrote:

 

But what you really can't do is convince a local host in that split subnet to access a remote host livinig in the same subnet with the subnet address.  They will just arp for a local answer.  And this is typically the requirement for the failover scenario at the application level.

 

---

With proxy-arp there are no problem.

Thanks for suggestion to consider DNS. I think it's the best choice in my case.