[j-nsp] SRX Static NAT - Not working in both directions

OBrien, Will ObrienH at missouri.edu
Fri Sep 7 20:32:01 EDT 2012


Config for your security policy? Nat is only half of it.

Will

On Sep 7, 2012, at 6:09 PM, "Oliver Garraux" <oliver at g.garraux.net> wrote:

> Brent, Patrick,
> 
> Thanks for the replies.
> 
> When I change the rule-set to apply to traffic from the user zone, I'm
> seeing the same behavior.  The source address on traffic from the
> desktop (192.168.35.200) out to the rest of the network isn't being
> NAT'ed.  I also can't initiate connections to 192.168.32.5 from the
> rest of my network.
> 
> I've also tried putting both the user and trust zones in the rule-set.
> In that scenario, I can connect to 192.168.32.5 from outside, but the
> outgoing traffic from 192.168.35.200 still isn't NAT'ed.
> 
> Thanks,
> 
> Oliver
> 
> -------------------------------------
> 
> Oliver Garraux
> Check out my blog:  www.GetSimpliciti.com/blog
> Follow me on Twitter:  twitter.com/olivergarraux
> 
> 
> On Fri, Sep 7, 2012 at 5:34 PM, Brent Jones <brent at brentrjones.com> wrote:
>> Try to apply the static NAT policy to zone 'user' and see how that goes.
>> 
>> On Fri, Sep 7, 2012 at 12:22 PM, Oliver Garraux <oliver at g.garraux.net> wrote:
>>> Hey,
>>> 
>>> I recently bought an SRX and have been trying the different NAT
>>> configuration options to become more familar with JunOS.
>>> 
>>> Static NAT isn't operating quite as I'd expect from the documentation.
>>> My understanding is that static NAT should be bidirectional, in that
>>> it should translate connections going in both directions.
>>> 
>>> I'm using 192.168.32.0/24 on the interface connected to the rest of my
>>> network (ge-0/0/0.100), and 192.168.35.0/24 on vlan.200 on my SRX.
>>> ge-0/0/0.100 is in the "trust" zone, and vlan.200 is in the "user"
>>> zone.
>>> 
>>> static {
>>>    rule-set user_to_trust {
>>>        from zone trust;
>>>        rule desktop1 {
>>>            match {
>>>                destination-address 192.168.32.5/32;
>>>            }
>>>            then {
>>>                static-nat prefix 192.168.35.200/32;
>>>            }
>>>        }
>>>    }
>>> }
>>> proxy-arp {
>>>    interface ge-0/0/0.100 {
>>>        address {
>>>            192.168.32.5/32;
>>>        }
>>>    }
>>> }
>>> 
>>> 
>>> I'm only seeing it translate connections coming in to the destination
>>> address (192.168.32.5).  The source address on connections initiated
>>> by the "static-nat" address (192.168.35.200 - the address on the
>>> desktop sitting behind my SRX) are not being translated to
>>> 192.168.32.5.  Am I misunderstanding how static NAT works?
>>> 
>>> I've tried using an IP that is routed to the SRX (where no proxy-arp
>>> should have been required in that situation).  I also don't see the
>>> address being translated when I look at these flows in "show security
>>> flow session", so I don't think this is an issue with proxy-arp.  I'm
>>> permitting all traffic between the "user" and "trust" zones (in both
>>> directions) in my security policies.
>>> 
>>> Here's one of the flow entries when I try to ping from 192.168.35.200
>>> to 192.168.17.16
>>> 
>>> Session ID: 21626, Policy name: permit-all/5, Timeout: 16, Valid
>>>  In: 192.168.35.200/25622 --> 192.168.17.16/1280;icmp, If: vlan.200,
>>> Pkts: 1, Bytes: 60
>>>  Out: 192.168.17.16/1280 --> 192.168.35.200/25622;icmp, If:
>>> ge-0/0/0.100, Pkts: 0, Bytes: 0
>>> 
>>> Any ideas?
>>> 
>>> Thanks,
>>> 
>>> Oliver
>>> 
>>> -------------------------------------
>>> 
>>> Oliver Garraux
>>> Check out my blog:  www.GetSimpliciti.com/blog
>>> Follow me on Twitter:  twitter.com/olivergarraux
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
>> 
>> 
>> --
>> Brent Jones
>> brent at brentrjones.com
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



More information about the juniper-nsp mailing list