SRX

Hi

 

So I have quite an interesting issue I am trying to deal with

 

This is in a lab and I am aware that there are much easier ways to do it but I am trying to understand why the way I am trying to do it fails

 

Consider L2L IPSEC VPN bt. SRX and ASA

 

 

            172.16.130.150-------ASA-------------L2L IPSEC----------------SRX-------------172.19.22.50 & .51

 

Now  I wanted to simulate the scenario where you have two discontiguous subnets on srx side so on ASA I defined crypto ACL as 

 

 

access-list VPN_ACL line 1 extended permit ip host 172.16.130.150 host 172.19.22.51 (hitcnt=30) 0x52145240
access-list VPN_ACL line 2 extended permit ip host 172.16.130.150 host 172.19.22.50 (hitcnt=44) 0x09fafd79

 

Correspondingly on SRX, 

 

sadm@SRX240# show security ipsec
traceoptions {
flag security-associations;
flag all;
}
proposal Phase2-Proposal {
authentication-algorithm hmac-md5-96;
encryption-algorithm 3des-cbc;
}
policy IPSEC-Policy {
proposals Phase2-Proposal;
}
vpn IPSEC-Tunnel-To-Bharat {
bind-interface st0.0;
ike {
gateway bharat-gw;
proxy-identity {
local 172.19.22.50/32;
remote 172.16.130.150/32;
}
ipsec-policy IPSEC-Policy;
}
}
vpn IPSEC-Tunnel-To-Bharat-Host-2 {
bind-interface st0.1;
ike {
gateway bharat-gw;
proxy-identity {
local 172.19.22.51/32;
remote 172.16.130.150/32;
}
ipsec-policy IPSEC-Policy;
}
}

 

 

 

sadm@SRX240# show routing-instances
vpn-route-instance {
instance-type virtual-router;
interface st0.0;
routing-options {
static {
route 172.16.130.150/32 next-hop st0.0;
route 0.0.0.0/0 next-hop 10.102.100.1;
}
}
}

 

 

sadm@SRX240# show firewall filter Blah
term capture {
from {
source-address {
172.19.22.50/32;
}
destination-address {
172.16.130.150/32;
}
}
then {
routing-instance vpn-route-instance;
}
}
term capture2 {
then accept;
}

 

What happens is if I try to initiate traffic from SRX side then I am able to ping 172.16.130.150 from both hosts on SRX butif I try to ping from ASA side then I can only ping .51 and not .50

 

.50 is the one which is using the routing instance above so looks like it has something to do with it. If I switch .50 and .51 and route .51 over vpn-route-instance then .51 fails and .50 works

 

 

On ASA I keep getting following error

 

May 31 2013 13:41:07: %ASA-2-106016: Deny IP spoof from (0.0.0.0) to 172.16.130.150 on interface outside

 

 

I am suspcting it has to do something with the routing instance and filter but I am trying to understand what else I can add

 

I am attaching entire SRX and ASA VPn/NAT configs as well

 

Thank You!

Any clues guys?

Hi

 

One reason for your setup not to work correctly is the following - you have st0.0 and st0.1 in different zones. When packet comes in from ASA, SRX checks reverse route back to source. If it points to the interface in a differen zone, then traffic will be dropped. So I propose to move both st0 units to vpn zone and repeat testing.

 

However I doubt it will fix the problem completely: in case of such asymmetric routing, you are going to have an asymmetric flow on ASA as well as on SRX. How to fix this depends also on what you finally want to acheive... I can probarbly help you with SRX side, but not with ASA's one.

Your config is a bit all over the place - you have one tunnel bound to untrust, and one bound to a vpn zone.  Looking closer at your config, the traffic going over st0.1 appears to be getting source-natted at the egress interface (becuase it is in the untrust zone).

 

Run your pings from both hosts again, and attach the output of "show security flow session protocol icmp" - that will give us a better idea about what is occuring.

Hi

 

Thank you both for your replies!

 

The reason I am trying to put st0.0 and st0.1 in two different zones is because I want to simulate scenario where you have multiple subnets behind SRX and single subnet behind ASA without using policy based vpn or NHTB

 

Thus, I created routing instance and filter

 

When I do pings srx to ASA side, it works from both the hosts behind srx and I can successfully ping host behind ASA. If I understand correctly this is happening because srx already knows about the session since it initiated from srx side and so  return traffic gets handled correctly

 

sadm@SRX240# run show security flow session

Session ID: 70780, Policy name: self-traffic-policy/1, Timeout: 1800, Valid

  In: 10.102.8.126/4933 --> 10.102.100.115/22;tcp, If: ge-0/0/15.0, Pkts: 2468, Bytes: 123580

  Out: 10.102.100.115/22 --> 10.102.8.126/4933;tcp, If: .local..0, Pkts: 3543, Bytes: 790045

 

Session ID: 107460, Policy name: self-traffic-policy/1, Timeout: 1800, Valid

  In: 10.102.8.126/2490 --> 10.102.100.115/22;tcp, If: ge-0/0/15.0, Pkts: 632, Bytes: 44580

  Out: 10.102.100.115/22 --> 10.102.8.126/2490;tcp, If: .local..0, Pkts: 490, Bytes: 60533

 

 

Session ID: 109957, Policy name: inbound/5, Timeout: 2, Valid

  In: 172.16.130.150/4 --> 172.19.22.51/64782;icmp, If: st0.1, Pkts: 1, Bytes: 84

  Out: 172.19.22.51/64782 --> 172.16.130.150/4;icmp, If: ge-0/0/14.0, Pkts: 1, Bytes: 84

 

 

Above sessions show nothing for 172.19.22.50 However on ASA I see equal no. of encaps/decaps when I look at Phase 2 SA associated with 172.19.22.50 IP (When pinging from ASA host to 22.50 host) which is really confusing

 

tcpdump on 172.19.22.50 shows no icmp packets hitting it

 

As seen here, In: 172.16.130.150/4 --> 172.19.22.51/64782;icmp, If: st0.1, Pkts: 1, Bytes: 84 the packet is incoming on st0.1 so similarly for 172.19.22.50 should coe in on st.0.0 and the reverse route check shouldn't fail?

 

Also

 

is it true that when using FBF, flow module is completely bypassed?

 

If that's true then would that be the reason why I am running into issues with this VPN?

 

Thanks!

Hi

 

No, that's totally wrong, flow module is still used, you need policies, etc. for traffic.

 

What is true, if you do FBF in the outbound direction, it will not affect sessions

initiated inbound.

Thanks pk

 

Appriciate your quick response!

So if I understand correctly,

 

I can use FBF to send certain traffic to a non-default routing instance and then still use security policies/static/dst nat as usual to manipulate that traffic?

 

The reason I ask is because FBF will happen before entering the flow module 

Hi

 

Correct, FBF applies only to route lookup during session setup. You still can/need to use policies, NAT, etc.

 

Although it is applied in stateless filter, it actually affects route lookup taken during "first path" (session setup) in the flow module.

What I am having hard time understanding is if I use a routing instance and in the filter "then" action says routing instance some-custom-routing-instance

If that "then routing-instance" corresponds to route lookup step in the flow module then in that case static nat dst nat have already been bypassed? So how can static dst nat be used when routing instance is being used as then action in the filter?

Sorry if the post sounds too convoluted and thanks for taking out time!

Hi All

 

ronydc86, I believe in this case D-NAT will be done first, and then D-NATed
address will be FBFed the way you configured. I haven't tested it however.

 

Alex, very interesting thing, thanks.

Hello,

It turns out I spoke too soon 

Virtual-routers are still required to ensure symmetric traffic across multiple policy-based IPSec SA, forwarding-instances and PPLB policy don't really cut it - asymmetric routing is possible where  pkts arrive into SRX on st0 unit A but exit via st0 unit B.

 

You can still use forwarding-instances and PPLB policy if the policy-based VPN box does not strictly check the src.IP of decapsulated pkt against remote proxy-id.

 

Below is the working config for SRX route-based IPSec VPN with multiple subnets and static NAT on SRX side:

 

2.2.2.5/32--[policy-based VPN box]=====ge-0/0/1[SRX]--10.10.10.10(static NATed to 1.1.1.5)
                 |                               |
2.2.2.6/32-------+                               +----10.10.10.11(static NATed to 1.1.1.6)

interfaces {
    ge-0/0/1 {
        description "untrust side";
        unit 0 {
            family inet {
                address 169.254.1.2/24;
            }
        }
    }
    ge-0/0/2 {
        description "trust side";
        unit 0 {
            family inet {
                filter {
                    input fbf;
                }
                address 10.10.10.1/24;
            }
        }
    }
    st0 {
        unit 1 {
            family inet;
        }
        unit 2 {
            family inet;
        }
    }
}
security {
    ike {
        proposal SRX-PHASE1 {
            description "Ph1";
            authentication-method pre-shared-keys;
            dh-group group2;
            authentication-algorithm sha1;
            encryption-algorithm des-cbc;
            lifetime-seconds 64800;
        }
        policy MO-IKE {
            mode main;
            proposals SRX-PHASE1;
            pre-shared-key ascii-text "$9$.mT36/t0OR3nylMWx7"; ## SECRET-DATA
        }
        gateway MO {
            ike-policy MO-IKE;
            address 169.254.1.1;
            external-interface ge-0/0/1.0;
        }
    }
    ipsec {
        proposal SRX-PHASE2 {
            description "Ph2";
            protocol esp;
            authentication-algorithm hmac-sha1-96;
            encryption-algorithm des-cbc;
            lifetime-seconds 64800;
        }
        policy MO-IPSEC {
            perfect-forward-secrecy {
                keys group2;
            }
            proposals SRX-PHASE2;
        }
        vpn TUN1 {
            bind-interface st0.1;
            ike {
                gateway MO;
                proxy-identity {
                    local 1.1.1.5/32;
                    remote 2.2.2.5/32;
                    service any;
                }
                ipsec-policy MO-IPSEC;
            }
            establish-tunnels immediately;
        }
        vpn TUN2 {
            bind-interface st0.2;
            ike {
                gateway MO;
                proxy-identity {
                    local 1.1.1.6/32;
                    remote 2.2.2.5/32;
                    service any;
                }
                ipsec-policy MO-IPSEC;
            }
            establish-tunnels immediately;
        }
    }
    flow {
        route-change-timeout 6;
        tcp-mss {
            ipsec-vpn {
                mss 1350;
            }
        }
    }
    nat {
        static {
            rule-set STATIC_NAT_OUTSIDE_IN {
                from zone [ untrust vpn vpn2 ];
                rule Test1 {
                    match {
                        destination-address 1.1.1.5/32;
                    }
                    then {
                        static-nat {
                            prefix {
                                10.10.10.10/32;
                                routing-instance default;
                            }
                        }
                    }
                }
                rule Test2 {
                    match {
                        destination-address 1.1.1.6/32;
                    }
                    then {
                        static-nat {
                            prefix {
                                10.10.10.11/32;
                                routing-instance default;
                            }
                        }
                    }
                }
            }
        }
    }
    policies {
        from-zone untrust to-zone untrust {
            policy allow-all {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone trust to-zone untrust {
            policy allow-any {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        default-policy {
            permit-all;
        }
        policy-rematch;
    }
    zones {
        security-zone untrust {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                ge-0/0/1.0;
                ge-0/0/0.0;
            }
        }
        security-zone trust {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                ge-0/0/2.0;
            }
        }
        security-zone vpn {
            host-inbound-traffic {
                system-services {
                    all;
                }
            }
            interfaces {
                st0.1;
            }
        }
        security-zone vpn2 {
            host-inbound-traffic {
                system-services {
                    all;
                }
            }
            interfaces {
                st0.2;
            }
        }
    }
}
firewall {
    family inet {
        filter fbf {
            term 1 {
                from {
                    source-address {
                        10.10.10.10/32;
                    }
                    destination-address {
                        2.2.2.5/32;
                    }
                }
                then {
                    count tun1;
                    routing-instance TUN1;
                }
            }
            term 2 {
                from {
                    source-address {
                        10.10.10.11/32;
                    }
                    destination-address {
                        2.2.2.5/32;
                    }
                }
                then {
                    count tun2;
                    routing-instance TUN2;
                }
            }
            term else {
                then accept;
            }
        }
    }
}
routing-instances {
    TUN1 {
        instance-type virtual-router;
        interface st0.1;
        routing-options {
            static {
                route 0.0.0.0/0 next-table inet.0;
                route 2.2.2.5/32 next-hop st0.1;
            }
        }
    }
    TUN2 {
        instance-type virtual-router;
        interface st0.2;
        routing-options {
            static {
                route 0.0.0.0/0 next-table inet.0;
                route 2.2.2.5/32 next-hop st0.2;
            }
        }
    }
}

 

HTH

Thanks

Alex

 

Hi peter, can you please help me on my topics. thank you

Hello,

I just finished debugging same problem and the root cause is that Your reverse route 172.16.130.150 is pointing only to single st0 unit. What You need to do is to configure 2 nexthops for 172.16.130.150 and load-balance policy:

 

routing-options {
    static {
        route 172.16.130.150/32 next-hop [ st0.0 st0.1 ];
    }
}
policy-options {
    policy-statement pplb {
        term 1 {
            then {
                load-balance per-packet;
            }
        }
    }
}
routing-options {
    forwarding-table {
        export pplb;
    }
}

 Also, it is VERY IMPORTANT to have this line in the config:

 

set security flow route-change-timeout 6

 Otherwise, Your nexthop reconfig won't take effect for existing sessions.

HTH

Thanks

Alex

 

[EDIT]

Also, You don't need virtual-routers, they complicate setup in case there are >2 zones. "instance-type forwarding"+static inside that instance+RIB-group to leak connected routes is enough.