SRX

Hi,

I have a number of SRX100 linked by static VPNs in a hub-and-spoke pattern, works fine. It's configured as a multidrop, and spokes can also access each other by passing through the hub.

I also have a dynamic VPN configured on the hub itself. Via this DynVPN I can access two different zones on the hub SRX100 itself, but I can't get it to allow access to other SRX100s and their respective local nets through the hub. 

I created policies according to KB23954 for the DynVPN. The zone "vpn" has the st0.0 multidrop interface for the static tunnels. The SRXs are all running Junos 12.1X44-D30.4. The policies I have on the hub related to the DynVPN are:

from-zone untrust to-zone servers {
    policy dynvpn-to-servers {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit {
                tunnel {
                    ipsec-vpn wizard_dyn_vpn;
                }
            }
        }
    }
}

from-zone untrust to-zone trust {
    policy dynvpn-to-trust {
        match {
            source-address dynvpn-ipnumbers;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}

from-zone untrust to-zone vpn {
    policy dynvpn-to-vpn {
        match {
            source-address dynvpn-ipnumbers;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}

 Before I go deep-diving into all this, my question is: is this even possible? Anyone know of a configuration example covering this?

This *should* work.  

I suspect your issue might be that your other SRX100s don't have a route configured back to the IP address range that your DynVPN clients are being allocated.  This subnet would need to be pointed down their st0.0 interfaces back towards the hub.

Hope this helps

I added both a static route and a destination with the hub DynVPN address pool for the policy back from the spoke SRX pointing to the IP number of the multidrop net for the hub SRX, but the problem remains unchanged.

Any more ideas of what can be wrong or some ninja debugging tips?

On the spoke SRX (mitm) where the server (mitm-osx-servers) is located that I want to be able to reach through the DynVPN at the hub (Uppsala), I now have the following. The "en-" nets are located at the hub and other spokes, and that routing works just fine.

I should point out that the hosts in "mitm-osx-servers" have IP numbers within the /24 class called "net-mitm-local".

set security zones security-zone vpn address-book address net-uppsala-dynvpn 10.10.10.0/24

policy trust-vpn-cfgr {
    match {
        source-address net-mitm-local;
        destination-address [ en-localnets en-servers en-voip net-uppsala-dynvpn ];
        application any;
    }
    then {
        permit;
    }
}

policy vpn-trust-cfgr {
    match {
        source-address [ en-localnets net-uppsala-dynvpn ];
        destination-address mitm-osx-servers;
        application any;
    }
    then {
        permit;
    }
}

static {
    route 0.0.0.0/0 next-hop 212.xxx.xxx.xxx;
    route 172.30.200.0/24 next-hop 172.30.50.1;
    ...
    route 10.10.10.0/24 next-hop 172.30.50.1;
}

A diagram may help here, as I'm not sure I fully understand your topology.

As for debugging, log your DynVPN client in and run a continuous ping to the servers you are trying to reach, then hop-by-hop use "show security flow session protocol icmp destination prefix x.x.x.x/32" and see what routing decisions are being made.

If you come to a box where there are no flows being recorded, then it's safe to say that your security policy is broken.

If you have a session that only shows packets for the session in one direction, then it's more than likely a routing issue.

Hope this helps! 

Ben,

Thx! Your debug tip did the trick. The problem was entirely outside what I described, so there's no way you could have found it. Sorry about that. 

If you look at the sketch, I have two firewalls on the net where the target server is, due to all kinds of legacy reasons. The default gateway is an SSG-5 I never mentioned, since I didn't think of it in this context. That one has a static permanent route pointing to the SRX100 on the same net for all the nets belonging to the spoke and hub system, that is, everything beyond the vpn tunnel over the multidrop 172.30.50.x net. I had forgotten to add the 10.10.10.0/24 DynVPN pool to the SSG-5, so those replies went right out the public IP 212.xxx.xxx.55 instead of to the SRX100 and the vpn tunnel.

Since I didn't mention that crucial piece of information (having more than one firewall on the net), my question was severely incomplete. But with your help, I found it. Thanks! (Now hoping the diagram shows up here...)

Regards,

Martin