SRX

I seem to be in an impossible situation, having just purchases a JunOS SRX100B.  I am running 12.1X44.4 firmware release.

Goals:

* NAT private traffic

* Route (not NAT) traffic from public server which has a publicly routable IP configured on it (hence no NAT involved here via SRX)

* IPv6-in-IPv4 HE Tunneling  - I had this working on SRX release 10.4, but involved the flow-based/packet-based work around wtih firewall rules.  Allegedly this workaround is not necessary anymore in release 11 and up, but without L3 connectivity on part of the RBI interface, the tunnel can never come up.

Problems Encountered:

1.) As stated, I want to be able to do NAT (L3) as well as Route (L2) using this one device.  I see people saying its not possible in some releases, but possible in others.  Its unbelievable this is a problem in any release. SSG does it fine, and to my knowledge so does JunOS firmware version 10.4.

I've tried using TRANSPARENT mode and the RBI (so called L3) interface, but the interface cannot route traffic, and refuses to NAT (because of Transparent mode usage).  L2 stuff, including IPv4 filtering, works fine in this mode.

I've tried ROUTE mode, but could not do security policies that would filter anything (as a result, ALL traffic inbound was allowed, even with the "default-policy deny-all" setting enabled.  (huge security bug IMHO)

2.) Flow mode does not work in Transparent mode, so I cannot add IPv6 addresses to security policies.  Thus, no filtering is possible, even if  I did have L3 connectivity (huge security bug IMHO)

So, did I make a mistake switching to JunOS?  My current thinking is that I should return this device and go with something else that actually does the job I tell it to, unless someone has a solution.

Thanks

Sorry, major typo

IRB interface, not RBI interface

Sorry

Is there a reason that using static NAT for the server in routing mode isn't an option?  If it is consider the following resources.  Note that you won't need NAT for any IPv6 servers on your LAN.

http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/example/nat-security-source-nat-egress-interface-configuring.html

http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/example/nat-security-static-single-address-translation-configuring.html

http://forums.juniper.net/t5/SRX-Services-Gateway/HE-IPv6-tunnel-with-flow-based-IPv6-in-10-4/td-p/69338/highlight/true/page/5

Thanks for the reply.  Please forgive my new username - for some reason, this site demanded I choose a name even though I already chose. 

At this point, anything is an option. I absolutely tore my network apart yesterday trying to find some way of making this work.  I ended up shutting off the SRX100 and writing an IPTables script to get my stuff working the way it once was.  BAM - back online 😃

The NAT instructions Juniper offers me in their KB articles never worked for inbound traffic (tried for hours across three distinct releases of firmware) - your URLs look very similar (in context) to the docs I used yesterday (though your links may  still be worth a shot). 

But to be honest, I really don't like NAT for servers.  I want my servers to route instead of NAT.  The only things that should use NAT are my users when they egress to the outside world. I dont like that I can't do "mixed" configurations like I could using an SSG and "binded" interfaces. 

I even tried making a "NON-Nat NAT policy for outbound purposes.  In other words:

set security nat source rule-set l2-trust from zone l2-trust 

set security nat source rule-set l2-trust to interface fe-0/0/0  (this is the public connected interface)

set security nat source rule-set l2-trust rule l2-egress match source-address x.x.x.x/x (public /32 or entire pub /29)

set security nat source rule-set l2-trust rule l2-egress then source-nat off

.... thinking that it would work the same, except without Network Address Translation.  It never worked unfortunately.

I am going to try to put together a diagram that will visually "tell the story of what I am trying to do".  I'm a little loopy from lack of sleep, and a little frustrated from the difficulties I have faced.    "Drawing" my intentions out may be beneficial for everyone.

In any rate, I thank you for your response.  I will review these links a little more indepth this morning and try to discern where I went wrong, either in practice or in logic.

Take care

Gropefruit / Gropefruit_1

OK, here is Phase-1 (We'll call this the "User Phase"):

And, here is Phase-2 (We'll call this the "Server Phase"):

An idea:

Since its (ironically) cheaper for me to buy a 2nd JunOS SRX100 than it is for me to return this SRX in exchange for an SSG20 or SSG5,  I am wondering if this is a better choice:

Buy a 2nd SRX100.

Have one SRX100 operate in TRANSPARENT MODE, filtering all L2 traffic from its connected clients.  This would be considered the "external" or "border" device, connecting my network to the outside world.

Have the second SRX100 operate in NAT mode, where all traffic is NAT'ed to one address, which is routed as-is to the upstream (first) SRX100. This SRX is a client of the "border/external" SRX.

HE tunneling would occur on the external (first) SRX100, and all IPv6-enabled clients internally would simply route out.

Hacky? Defeatist?   I can't decide ....  given the loss of "mixability between L2 and L3" I can't help but wonder if this is what Juniper WANTS us to do ........

Ah wait, that won't work.

I can't filter IPv6 traffic in Transparent mode according to recent error messages indicating such.

----

So I guess Im back to 'Square One / Impossible Situation'.....

OK, I am going to consider this issue closed unsuccessfully.

I'll be ditching the SRX100 and going with an SSG20, as I already know this will work.

Thanks to those who helped, and a warning to those considering the switch from ScreenOS to JunOS:

--> Don't do it <--

Sorry to see you have made up your mid so quickly, however i think what you ar looking for is Selective Packet-Mode Forwarding. And you would simply create a firewall filter family inet with a term X from SA <IP_Address> then packet-mode. Apply that filter on as an input filter on he interface you want to bypass the natting and be routed directly. Of course you have the desired route already created fro the traffic you want to bypass natting.

http://www.juniper.net/us/en/local/pdf/app-notes/3500192-en.pdf

Remember that the SRX was built from the Screen os. I am pretty sure whatever you can do in the ScreenoS can be done in SRX Junos.:)

Thanks for the reply!

I unfortunately needed a working solution sooner, and the inconsistent/non-specific documentation I found did not bode well for future adoption.  All of the docs I found seemed to imply "sorry, you have to NAT on the device; no L2 routing".  Furthermore, my network was hard down using JunOS.  We're a small shop, and we have limited hardware/funds to produce a QA-like POC demo.  We trusted Juniper to do something we wanted, simply, and they failed.  Its our fault for trusting them.

I am glad an intelligent engineer such as yourself proposed a solution that indeed may well work, but in my opinion Juniper needs to learn from this egregious difficulty-in-configuration.  I should not have to create some elaborate solution to produce a very (VERY) simple result for such a unsophisticated networking topology, nor should I have to be a certified network engineer to produce the same result. 

I'd like to use the same knowledge I've used for the past decade, ideally.  Anyone is free to curse me as "a  network noob who is stuck in the past" -- I won't argue.  I stand by these experiences and my convictions based on every other networking-related incident I have ever experienced in my professional career.

Juniper - I hope you learned something as well.  I know you read these forums.  Take this thread to heart and re-evaluate ScreenOS targeted at 'simpler' users.   However, I thank you for still offering ScreenOS, even if the support contract for an SSG20 is 75% more expensive than that of an SRX100  - I am HAPPY to pay it to make stuff work.

Take care everyone!

G

I understand. I have been suggesting that for years. I just don't check the forums often enough. When I do I end up spending a lot of time and right now I am studying several different juniper technologies. All at once. A fool I am, but I will get one of them eventually. Hopefully, you will reconsider. Juniper is pretty strong product and very efficient based on its architecture. if I were to be a sales person, I would sell Juniper products and probably exclusively. Thanks

In studying, I found this information so you can use it for future implementations and others can find it here if they have the question also:

• Transparent mode support for IPv6 flows—This feature is supported on all high-end SRX Series devices.

  In transparent mode, the SRX Series device filters packets that traverse the device without modifying any of the source or destination information in the packet MAC headers. Transparent mode is useful for protecting servers that mainly receive traffic from untrusted sources because there is no need to reconfigure the IP settings of routers or protected servers. In Junos OS Release 12.1X44-D10, IPv6 traffic is supported for transparent mode on the specified SRX Series devices.

  A device operates in Layer 2 transparent mode when all physical interfaces on the device are configured as Layer 2 interfaces. There is no command to define or enable transparent mode on the device. The device operates in transparent mode when there are interfaces defined as Layer 2 interfaces. The device operates in route mode (the default mode) if there are no physical interfaces configured as Layer 2 interfaces.

  By default, IPv6 flows are dropped on security devices. To enable processing by security features such as zones, screens, and firewall policies, you must enable flow-based forwarding for IPv6 traffic with themode flow-based configuration option at the [edit security forwarding-options family inet6] hierarchy level. A device reboot is required when you change the mode.

  Configuring bridge domains and Layer 2 logical interfaces for IPv6 flows is the same as configuring bridge domains and Layer 2 logical interfaces for IPv4 flows. You can optionally configure an integrated routing and bridging (IRB) interface for management traffic in a bridge domain. The IRB interface is the only Layer 3 interface allowed in transparent mode. The IRB interface on the SRX Series device does not support traffic forwarding or routing. The IRB interface can be configured with both IPv4 and IPv6 addresses.

  [Understanding IPv6 Flows in Transparent Mode]

• 64-bit support for Junos OS security features—This feature is supported on all high-end SRX Series devices.

  The 64-bit support increases the session scalability for both the SPC and the central point. The exact increase in the session scalability also depends on whether IDP is enabled or not for the application and on the configuration such as combo Services Processing Unit (SPU). The 64-bit support also increases the capacity for various services such as NAT, ALG, GTP, and so on.