SRX

Hi,

I'm trying to configure a static ipsec tunnel between an SRX240 and a Linux host (using racoon).  It is now to the point where I have the security-associations showing so the tunnel seems to be active.  I can ping from either side and see the ESP packets going to the other side, but neither end responds to the ping (the ESP packet is dropped maybe?).  I can even use wireshark to decrypt the packets (using the keys from the Linux side) and I see that the contents are the ping packets with the correct private IPs inside.

Any ideas why the SRX side isn't responding to a ping?  (If I could at least get the SRX side to respond... I can work on the Linux side from there...)

My network setup is as follows:

SRX Public IP: a.b.c.d   -- Internet zone, on reth0.0

Linux Public IP: e.f.g.h

SRX VPN IP: 172.16.41.1/24  -- VPNRemote zone, on st0.0 (multipoint)

Linux VPN IP: 172.16.41.51

The goal is to set up a GRE tunnel so that several private IP ranges from the SRX side are accessible from the Linux side.

Here is my configuration so far:

interfaces {
    reth0 { ... } /* Internet interface */
    st0 {
        unit 0 {
            multipoint;
            family inet {
                next-hop-tunnel 172.16.41.51 ipsec-vpn ike-vpn-test;
                address 172.16.41.1/24;
            }
        }
    }
}
security {
    ike {
        proposal ike-phase1-proposal {
            authentication-method pre-shared-keys;
            dh-group group2;
            authentication-algorithm sha-256;
            encryption-algorithm aes-256-cbc;
        }
        policy ikep1-test-policy {
            mode main;
            proposals ike-phase1-proposal;
            pre-shared-key ascii-text "$9$qfF/u0IcSeuOhrlK7N"; ## SECRET-DATA
        }
        gateway test {
            ike-policy ikep1-test-policy;
            address e.f.g.h;
            external-interface reth0.0;
        }
    }
    ipsec {
        proposal ipsec-phase2-proposal {
            protocol esp;
            authentication-algorithm hmac-sha-256-128;
            encryption-algorithm aes-256-cbc;
        }
        policy ipsec-test-policy {
            perfect-forward-secrecy {
                keys group2;
            }
            proposals ipsec-phase2-proposal;
        }
        vpn ike-vpn-test {
            bind-interface st0.0;
            ike {
                gateway test;
                proxy-identity {
                    local 172.16.41.0/24;
                    remote 172.16.41.51/32;
                }
                ipsec-policy ipsec-test-policy;
            }
            establish-tunnels immediately;
        }
    }
    policies {
        from-zone junos-host to-zone VPNRemote {
            policy test {
                match {
                    source-address any;
                    destination-address VPNNet;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone VPNRemote to-zone junos-host {
            policy test {
                match {
                    source-address any;
                    destination-address VPNNet;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    zones {
        security-zone Internet {
            screen Internet-screen;
            host-inbound-traffic {
                system-services {
                    ike;
                }
            }
            interfaces {
                reth0.0;
            }
        }
        security-zone VPNRemote {
            address-book {
                address VPNNet 172.16.41.0/24;
            }
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                st0.0;
            }
        }
    }
}

Linux:

ipsec.conf:

spdadd 172.16.41.51 172.16.41.0/24 any -P out ipsec
   esp/tunnel/e.f.g.h-a.b.c.d/require;
spdadd 172.16.41.0/24 172.16.41.51 any -P in ipsec
   esp/tunnel/a.b.c.d-e.f.g.h/require;


racoon.conf:

remote a.b.c.d [500] {
        exchange_mode main;
        peers_identifier_address a.b.c.d;
        my_identifier_address e.f.g.h;
        verify_identifier off;
        nat_traversal force;
        proposal {
                encryption_algorithm aes 256;
                hash_algorithm sha256;
                authentication_method pre_shared_key;
                dh_group 2;
        }
}


psk.conf:

a.b.c.d secret

Security associations seem to be okay:

root@fw01> show security ike security-associations
node0:
--------------------------------------------------------------------------
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address
5116024 UP     77fa7eaeb2f0f554  280affa8d6d30521  Main           e.f.g.h  

----

root@fw01> show security ipsec security-associations
node0:
--------------------------------------------------------------------------
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon vsys Port  Gateway
  <131073 ESP:aes-256/sha256 fbd041eb 2538/ unlim - root 4500 e.f.g.h
  >131073 ESP:aes-256/sha256 561bcf4 2538/ unlim - root 4500  e.f.g.h

When I ping from Linx to SRX, I can see the packets going out from Linux:

09:26:34.544851 IP e.f.g.h.4500 > a.b.c.d.4500: UDP-encap: ESP(spi=0xfbd041eb,seq=0x94), length 132
09:26:35.552884 IP e.f.g.h.4500 > a.b.c.d.4500: UDP-encap: ESP(spi=0xfbd041eb,seq=0x95), length 132
09:26:36.560938 IP e.f.g.h.4500 > a.b.c.d.4500: UDP-encap: ESP(spi=0xfbd041eb,seq=0x96), length 132

(and once decrypted they are pings from 172.16.41.51 to 172.16.41.1)

Showing a flow trace of the above pings using basic-datapath:

root@fw01> show log tshoot_ipsec
May  8 09:26:31 09:26:31.534228:CID-1:RT: find flow: table 0x491ef1f8, hash 36516(0xffff), sa e.f.g.h, da a.b.c.d, sp 64464, dp 16875, proto 50, tok 7
May  8 09:26:32 09:26:31.534228:CID-1:RT:  flow got session.
May  8 09:26:32 09:26:31.534228:CID-1:RT:  flow session id 20459
May  8 09:26:32 09:26:31.534228:CID-1:RT:  flow_decrypt: tun 4cca38b8(flag 8a), iif 67
May  8 09:26:32 09:26:31.534228:CID-1:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)

May  8 09:26:32 09:26:32.542209:CID-1:RT:<e.f.g.h/4500->a.b.c.d/4500;17> matched filter zzz:
May  8 09:26:32 09:26:32.542209:CID-1:RT:packet [160] ipid = 59560, @42370d9c
May  8 09:26:32 09:26:32.542209:CID-1:RT:---- flow_process_pkt: (thd 3): flow_ctxt type 15, common flag 0x0, mbuf 0x42370b80, rtbl_idx = 0
May  8 09:26:32 09:26:32.542209:CID-1:RT: flow process pak fast ifl 67 in_ifp reth0.0
May  8 09:26:32 09:26:32.542209:CID-1:RT:  reth0.0:e.f.g.h/4500->a.b.c.d/4500, udp
May  8 09:26:32 09:26:32.542209:CID-1:RT: find flow: table 0x491ef1f8, hash 49795(0xffff), sa e.f.g.h, da a.b.c.d, sp 4500, dp 4500, proto 17, tok 7
May  8 09:26:32 09:26:32.542209:CID-1:RT:  flow got session.
May  8 09:26:32 09:26:32.542209:CID-1:RT:  flow session id 99003
May  8 09:26:32 09:26:32.542209:CID-1:RT:  flow_decrypt: tun 4ee324b8(flag 10), iif 67
May  8 09:26:32 09:26:32.542209:CID-1:RT:dec vector=83bd0d8.
May  8 09:26:32 09:26:32.542209:CID-1:RT:In natt_decap Completed NATT decap
May  8 09:26:32 09:26:32.542209:CID-1:RT:In natt_decap After NATT decap, pak_ptr->src=e.f.g.h and pak_ptr->dst = a.b.c.d
May  8 09:26:32 09:26:32.542209:CID-1:RT:dec vector=83bd0d8. rc 0x0
May  8 09:26:32 09:26:32.542209:CID-1:RT:  reth0.0:e.f.g.h->a.b.c.d, 50
May  8 09:26:32 09:26:32.542209:CID-1:RT: find flow: table 0x491ef1f8, hash 36516(0xffff), sa e.f.g.h, da a.b.c.d, sp 64464, dp 16875, proto 50, tok 7
May  8 09:26:32 09:26:32.542209:CID-1:RT:  flow got session.
May  8 09:26:32 09:26:32.542209:CID-1:RT:  flow session id 20459
May  8 09:26:32 09:26:32.542209:CID-1:RT:  flow_decrypt: tun 4cca38b8(flag 8a), iif 67
May  8 09:26:32 09:26:32.542209:CID-1:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)


May  8 09:26:33 09:26:33.550175:CID-1:RT:<e.f.g.h/4500->a.b.c.d/4500;17> matched filter zzz:
May  8 09:26:33 09:26:33.550175:CID-1:RT:packet [160] ipid = 59711, @4238839c
May  8 09:26:33 09:26:33.550175:CID-1:RT:---- flow_process_pkt: (thd 2): flow_ctxt type 15, common flag 0x0, mbuf 0x42388180, rtbl_idx = 0
May  8 09:26:33 09:26:33.550175:CID-1:RT: flow process pak fast ifl 67 in_ifp reth0.0
May  8 09:26:33 09:26:33.550175:CID-1:RT:  reth0.0:e.f.g.h/4500->a.b.c.d/4500, udp
May  8 09:26:33 09:26:33.550175:CID-1:RT: find flow: table 0x491ef1f8, hash 49795(0xffff), sa e.f.g.h, da a.b.c.d, sp 4500, dp 4500, proto 17, tok 7
May  8 09:26:33 09:26:33.550175:CID-1:RT:  flow got session.
May  8 09:26:33 09:26:33.550175:CID-1:RT:  flow session id 99003
May  8 09:26:33 09:26:33.550175:CID-1:RT:  flow_decrypt: tun 4ee324b8(flag 10), iif 67
May  8 09:26:33 09:26:33.550175:CID-1:RT:dec vector=83bd0d8.
May  8 09:26:33 09:26:33.550175:CID-1:RT:In natt_decap Completed NATT decap
May  8 09:26:33 09:26:33.550175:CID-1:RT:In natt_decap After NATT decap, pak_ptr->src=e.f.g.h and pak_ptr->dst = a.b.c.d

May  8 09:26:33 09:26:33.550175:CID-1:RT:dec vector=83bd0d8. rc 0x0
May  8 09:26:33 09:26:33.550175:CID-1:RT:  reth0.0:e.f.g.h->a.b.c.d, 50
May  8 09:26:33 09:26:33.550175:CID-1:RT: find flow: table 0x491ef1f8, hash 36516(0xffff), sa e.f.g.h, da a.b.c.d, sp 64464, dp 16875, proto 50, tok 7
May  8 09:26:33 09:26:33.550175:CID-1:RT:  flow got session.

May  8 09:26:33 09:26:33.550175:CID-1:RT:  flow session id 20459
May  8 09:26:33 09:26:33.550175:CID-1:RT:  flow_decrypt: tun 4cca38b8(flag 8a), iif 67
May  8 09:26:33 09:26:33.550175:CID-1:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)


May  8 09:26:33 09:26:33.944179:CID-1:RT:<e.f.g.h/4500->a.b.c.d/4500;17> matched filter zzz:
May  8 09:26:33 09:26:33.944246:CID-1:RT:packet [29] ipid = 24964, @423b3c9c
May  8 09:26:33 09:26:33.944246:CID-1:RT:---- flow_process_pkt: (thd 2): flow_ctxt type 15, common flag 0x0, mbuf 0x423b3a80, rtbl_idx = 0

May  8 09:26:33 09:26:33.944246:CID-1:RT: flow process pak fast ifl 67 in_ifp reth0.0
May  8 09:26:33 09:26:33.944246:CID-1:RT:  reth0.0:e.f.g.h/4500->a.b.c.d/4500, udp
May  8 09:26:33 09:26:33.944320:CID-1:RT: find flow: table 0x491ef1f8, hash 49795(0xffff), sa e.f.g.h, da a.b.c.d, sp 4500, dp 4500, proto 17, tok 7
May  8 09:26:33 09:26:33.944381:CID-1:RT:  flow got session.
May  8 09:26:33 09:26:33.944381:CID-1:RT:  flow session id 99003
May  8 09:26:33 09:26:33.944381:CID-1:RT:  flow_decrypt: tun 4ee324b8(flag 10), iif 67
May  8 09:26:33 09:26:33.944381:CID-1:RT:dec vector=83bd0d8.
May  8 09:26:33 09:26:33.944381:CID-1:RT:dec vector=83bd0d8. rc 0xffffffff
May  8 09:26:33 09:26:33.944443:CID-1:RT:<e.f.g.h/4500->a.b.c.d/4500;17> matched filter zzz:
May  8 09:26:33 09:26:33.944443:CID-1:RT:packet [29] ipid = 24964, @423b3c9c
May  8 09:26:33 09:26:33.944496:CID-1:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)

So it looks like the packets are received at the SRX end, and it shows "flow_decrypt tun ..." and then that's it?

Do you have a static route pointing the 172.16.41.0/24 subnet to the st0.0 interface?

If so, is this route active in show route to the correct interface?

Also, your security policy is correct for ping to the SRX self traffic.  But you probably need additional policies for the VPN subnet to the other local subnets zones for the actual traffic to pass.

Hi,

I didn't add a static route manually, but because of the interface address being /24, it appears as though there is a route out st0.0:

root@fw01> show route
...
0.0.0.0/0          *[Static/5] 32w6d 23:52:37
                    > to a.b.c.x via reth0.0
172.16.41.0/24     *[Direct/0] 02:03:15
                    > via st0.0
172.16.41.1/32     *[Local/0] 1w2d 00:32:06
                      Local via st0.0

I didn't show pings from the SRX to Linux, but "ping 172.16.41.51" from the SRX does show the right encrypted traffic:

11:28:37.241479 IP a.b.c.d.4500 > e.f.g.h.4500: UDP-encap: ESP(spi=0x04ae67bc,seq=0xc), length 136

(and decrypted that is a ping from 172.16.41.1 to 172.16.41.51)

So the SRX seems to know how route traffic out the VPN link too, but not accept anything incoming.

Thanks for the reminder about the security policy.  I was trying to get the basics going first and then I will have to add policies for internal traffic on each side.

You don't want that subnet on your st0.0 interface if this is the remote LAN segment.  This causes the SRX to see the subnet as local and layer2.

you can just make the st0.0 interface unnumbered in this scenario instead.

Please do add the route so the traffic to the remote LAN will be sent into the tunnel.

The subnets on each far side of the gateways are in the 10.x.x.x ranges (a few different ones as a couple subnets are connected to the SRX).  I saw in some examples that others were using a GRE tunnel over the VPN, so I thought I would get the ipsec going and then once I can ping I would set up a GRE tunnel and route the 10.x.x.x through that level for easier management on both sides.  I'm not there yet.

With a multipoint tunnel, the /24 is what seems to be the way to go?  Eventually there will be another connection, so the SRX will be a hub in a hub-and-spoke type setup.   I thought the multipoint with another address in the 172.16.41.x range for the next spoke would be the way to go.  Is that overcomplicating things right now?

The other thing that I've noticed is that the statistics show no decrypted packets and no errors from the incoming pings.

root@fw01> show security ipsec statistics
node0:
--------------------------------------------------------------------------

ESP Statistics:
  Encrypted bytes:            51484
  Decrypted bytes:                0
  Encrypted packets:            329
  Decrypted packets:              0
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

Could that be an indication that the ipsec decryption isn't working when the SRX receives the ESP packets?

I'm probably a little confused.

What is the source ip address and destination ip address of the ping attempt?

Typically these would be interfaces outside the tunnel interfaces themselves:

port --- tunnel --- port

The source address of the ping needs to have the return route.

If you are going to doi GRE over IPSEC then these are separate ip addresses and ranges.  This would be the interface ip address routed down the tunnel.

then the GRE interface will have routes for the LAN subnets on the other side and pointed to the GRE interface.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB19372

In any case you have a static route into the tunnel for the ip address behind the tunnel interface getting the traffic.

I followed the directions in the link provided.  Here is are the parts of the configuration that I've changed:

interfaces {
    gr-0/0/0 {
        unit 0 {
            tunnel {                    
                source 172.16.41.1;
                destination 172.16.41.51;
            }
            family inet {
                address 172.16.42.1/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 172.16.41.1/32;
            }
        }
    }
    st0 {
        unit 0 {
            family inet;
        }
    }
}
routing-options {
    static {
        route 0.0.0.0/0 next-hop inetgw;
        route 172.16.41.51/32 next-hop st0.0;
    }
}
security {
    zones {
        security-zone VPNRemote {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {             
                    all;
                }
            }
            interfaces {
                gr-0/0/0.0;
                st0.0;
                lo0.0;
            }
        }
    }
}

(I'm not sure why they use lo0 for the VPN ip, but I followed it anyway.)  The security policy from VPN -> junos-host allows from any to any, so that should not get in the way.

From linux, I tried to ping 172.16.41.1 and 172.16.42.1.  I can see the ESP network traffic.  Once decrypted in wireshark, I have a ping from 172.16.41.51 -> 172.16.41.1 (tried this first), and gre tunnelled 172.16.42.51 -> 172.16.42.1 (tried this second).

In all cases there is no return traffic from the SRX.  The flow traceoptions that I have set up shows the packet coming in and ending with "flow_decrypt: tun 4f32b878(flag 10), iif 67", but no further processing of the decrypted packet.

One thing that I stumbled across is the interface statistics:

root@fw01> show interfaces extensive reth0.0                   
  Logical interface reth0.0 (Index 67) (SNMP ifIndex 553) (Generation 132)
...
   Flow Input statistics :
      Self packets :                     2
      ICMP packets :                     0
      VPN packets :                      53
...
    Flow error statistics (Packets dropped due to): 
      Address spoofing:                  0
      Authentication failed:             9
...

This seems to increase for every ESP packet received (the tunnelled pings).  What does the Authentication Failed counter mean?  The best description that I could find was "The packet was dropped because the IPsec Encapsulating Security Payload (ESP) or Authentication Header (AH) authentication failed."...  but the security-associations are showing on both sides with the same SPI values, so I'm not sure how to go about debugging this further.

Thanks!

The loopback is just an alternative to using an interface as a gateway, either will be fine.

You are missing the routes for addresses that will go into the GRE tunnel with a next hop of the GRE interface.

And you ping test is still from tunnel interface to tunnel interface not yet the LAN subnets encapsulated in the tunnel.  Once you have the GRE routes in place run the ping from the local subnet interface source on the SRX to the remote side GRE LAN addresses end to end.

Hi,

Yes, I was missing routes and that was part of the issue.  However, I still could not ping from networks behind each gateway or from/to the gateways themselves.  Like before, traffic was leaving the Linux end but not being decrypted at the SRX (and vice versa).

I was thinking about the Authentication failures counter from before and started wondering if I had a problem the ipsec algorithms or keys.  The change that I made that fixed things was instead of using hmac-sha-256-128 I changed this to hmac-sha1-96 (and changed the Linux side to sha1 as well).

Now my ipsec proposal looks like:

proposal ipsec-phase2-proposal {
    protocol esp;
    authentication-algorithm hmac-sha1-96;
    encryption-algorithm aes-256-cbc;
}

Now I can see that packets are being decrypted when received in the traceoptions log file.  After fixing the routes as you suggested and adding some policies t o/from the various networks, the tunnel is working as expected.

In short, it seems that there is some incompatibility between racoon on Linux and the SRX in their implementation of sha256.

Thank you for all of your help!