SRX

 View Only
last person joined: yesterday 

Ask questions and share experiences about the SRX Series, vSRX, and cSRX.
  • 1.  policy based VPN with src nat to non-SRX peer

    Posted 03-13-2013 14:50

    I am just testing out different scenarios in lab to understand why certain things won't work

     

    Here's how my lab is setup

     

    172.19.22.50 (natted to 1.1.1.1)--------SRX----------IPSEC tunnel---------ASA-----172.16.130.1

     

     

    When I try to set up src-nat for policy based vpn (other end is ASA); and use private/real IPs in the policies on SRX the tunnel does come up but won't pass any traffic and ASA will throw following errors

     

    %ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0x4AB132C2, sequence number= 0x146) from 10.102.100.115 (user= 10.102.100.115) to 10.102.101.102.
    The decapsulated inner packet doesn't match the negotiated policy in the SA. 
    The packet specifies its destination as 172.16.130.1, its source as 1.1.1.1, and its protocol as icmp. 
    The SA specifies its local proxy as 172.16.130.1/255.255.255.255/ip/0 and its remote_proxy as 172.19.22.50/255.255.255.255/ip/0.
    %ASA-3-313001: Denied ICMP type=8, code=0 from 1.1.1.1 on interface outside
    %ASA-7-609002: Teardown local-host outside:1.1.1.1 duration 0:00:00

     

    I understand what's happening above since 172.19.22.50 is a real server behind srx ceing src-natted to 1.1.1.1 and 172.16.130.1 is behind ASA

    In the policies on SRX, they are setup to be from 172.19.22.50 to 172.16.130.1 so I understand that it's grabbing proxy IDs from the policies and hence the o/p above is as expected.

     

    Now on SRX if I change policies and replace 172.19.22.50 (server behind SRX) with 1.1.1.1 (It's natted IP) then policy from trust to untrust will never be hit since src-nat will happen after policy look up andthust trust to untrust policy allowing traffic from 1.1.1.1 to 172.16.130.1 will never be hit and tunnel won't ever come up. That's what the lab is showing me.

     

    Does the above scenario seem correct to you guys? Do you think it implies taht we can never use src-nat with policy based vpn when other end is non SRX?

     

    Have you ever gotten policy based with non srx peer working?

     

    Sorry for such a long post and I know this scenario would be much easier done via route based vpn but I really want to get to the root of this. Thanks!



  • 2.  RE: policy based VPN with src nat to non-SRX peer

    Posted 03-13-2013 15:03

    Based on the part of the error message from the ASA that you highlighted in bold, it looks like you need to change your ACL on the ASA.

     

    The ASA is expecting the traffic to be coming from 172.19.22.50, but you're NATting it to 1.1.1.1, so the ASA needs to have its ACL set to expect traffic from 1.1.1.1.

     



  • 3.  RE: policy based VPN with src nat to non-SRX peer

    Posted 03-13-2013 15:17

     

    Here's the thing though,

     

    After changing to 1.1.1.1 on ASA, tunnel will never even be attempted to be brought up by SRX

     

    If I want to change to 1.1.1.1 on ASA, how do I modify the policies on SRX?

     

    If I keep them the same then proxy IDs sent across from SRX to ASA will contain private IPs and ASA will reject that as shown above

     

    If I change the policies on SRX so that on trust to untrust it is from 1.1.1.1 to 172.16.130.1 then that policy will never be hit on SRX since policy lookup is happening before Src-nat

     

    Catch 22?



  • 4.  RE: policy based VPN with src nat to non-SRX peer

    Posted 03-14-2013 11:48

    After changing to 1.1.1.1 on ASA, tunnel will never even be attempted to be brought up by SRX


    I don't see how making a change on the ASA would cause the SRX to behave differently...

     

    Are you initiating the traffic from behind the SRX, or behind the ASA?

     

    Personally I don't do NAT with policy-based VPNs.  Route-based are much better for this.  I have seen others state that they do NAT with PB-VPNs successfully, but I don't know offhand what the magic sauce is that has to be sprinkled on things to make them work.

     

    Could you post your full SRX config (as an attachment please, don't paste it into the message body) and the relevants parts of your ASA config (ACLs, crypto maps, etc.)?  If anything jumps out at me I'll let you know, otherwise maybe some of the others who have done NAT with PB-VPNs can weigh in.

     



  • 5.  RE: policy based VPN with src nat to non-SRX peer

    Posted 03-14-2013 13:56
      |   view attached

     

    Hi

     

    After changing crypto acl on ASA to 1.1.1.1 I will have to change policies on SRX to include 1.1.1.1 in the policy instead of 172.19.22.50 so that it sends the proxy ids to ASA that ASA is expecting.

     

    But if I do that then when SRX is trying to initiate traffic, those policies will never be hit since policy lookup will happen before src-nat and thus srx will never try to bring the tunnel up.

     

    My attachment has relevant config and some more comments in there to help clear up what I am trying to get to.

     

    I understand that route based is a much easier way to go. But I am trying it in a lab environment to understand why certain things won't work

     

    Thanks!


    #IPSec
    #vpn
    #ASA

    Attachment(s)

    txt
    srx+asa+my comments.txt   5 KB 1 version


  • 6.  RE: policy based VPN with src nat to non-SRX peer
    Best Answer

    Posted 03-14-2013 16:01

    @ronydc86 wrote:

     

    After changing crypto acl on ASA to 1.1.1.1 I will have to change policies on SRX to include 1.1.1.1 in the policy instead of 172.19.22.50 so that it sends the proxy ids to ASA that ASA is expecting.

     

    But if I do that then when SRX is trying to initiate traffic, those policies will never be hit since policy lookup will happen before src-nat and thus srx will never try to bring the tunnel up.


    That's why I don't mess with PB-VPNs and NAT.  Smiley Wink

     

    At one point I thought I remembered reading somewhere that you could set the proxy ID for policy-based VPNs, but as was recently discussed in another discussion thread started by you on this same issue, it looks like it doesn't actually work that way or at least not in the test cases that have been performed.

     

    I also thought I'd seen some folks around here say that they've done NAT with PB-VPNs, but maybe not... 

     

    Perhaps what I was thinking of was on the ScreenOS boxes... the info gets jumbled in my head sometimes.

     

    When I looked at your configs the networks and object names jogged my memory back to that other thread, so it looks like we're still trying to solve the same problem as what was previously discussed?

    pk tested it in a lab setup and got different results than you reported.

     

    Have you confirmed with JTAC which is the expected behavior?  Perhaps file a bug report that the proxy-ID knob should throw a commit error if the VPN isn't configured with a bind-interface to make it a route-based VPN to remove confusion?

     

    If the proxy-id knob doesn't actually work for PB-VPNs, then I think the simple answer here is that it's not going to work that way.  Just pretend the proxy-ID knob doesn't exist for PB-VPNs and if you have to do NAT in your VPN, use a route-based VPN.

     

    It's kind of like trying to make a car drive sideways.