Multiple VPNs setup with a Juniper SRX320.

The SRX320 has an irb interface as follows:

  irb {
    unit 0 {
        family inet {

I've setup a dynamic VPN that I'm connecting to over the JuneOS Pulse software, using the same pool as all physically connected devices:

pool pool1 {
        family inet {
            dhcp-attributes {
                name-server {
                router {

Remote resources are defined here:

dynamic-vpn {
    access-profile dyn-vpn;
    clients {
        all {
            remote-protected-resources {

Policy set here:

    from-zone Untrust to-zone trust {
        policy dyn-vpn-trust {
            match {
                source-address any;
                destination-address any;
                application any;
            then {
                permit {
                    tunnel {
                        ipsec-vpn dyn-vpn;

So when I connect to the dyn-vpn:

  • I can see the routes getting passed down to me properly.
  • I can ping
  • I CANNOT ping any other address (like the name server, or the DC, or anything else.
  • I can hit everything else inside (the other VPNs, for instance

If I change my pool assignment to a new pool and assign it to, I can ping everything within but I can no longer access my other VPNs. They are unaware of the route because that subnet is not being routed. I could put static assignments in and rig it but I feel like I'm lacking something basic in my understanding and I'd like to learn. The firewall clearly knows the route to me, as it responds from pings to the irb interface; so why will it not route any other .120 address?

If I missed a config that you need to know, let me know.

  • Do your other devices have a route back to you?
    – Ron Trunk
    Feb 23, 2019 at 10:45
  • All the devices I want to hit are assigned addresses in the block. I would assume they have a route to me, right? Their default gateway is
    – patterned
    Feb 23, 2019 at 14:33
  • There is no such thing as a Sonicwall SRX320. You're probably talking about a Juniper SRX 320, and the configuration style does look like Juniper a lot. Feb 27, 2019 at 11:21
  • Oh lord. Thanks for catching that Marc. Not sure why sonicwall was on the brain. Maybe that's why I'm not getting attention :X
    – patterned
    Feb 27, 2019 at 12:52
  • Do other devices in have ARP resolution for the 192.168.120.x assigned to the connected clients? If hosts on want to talk (or respond) to any device in, they will attempt an ARP resolution for the IP address and they will expect some response. Else, no packets will be going back. Maybe your VPN connected client can in fact reach the domain controller, but the DC is unable to respond... Feb 27, 2019 at 16:31

1 Answer 1


The subnet your allocate from pool1 is routed from the SRX to your VPN tunnel - it's not bridged into the existing subnet hanging off irb.1.

I suspect the SRX has a host route (/32) to your client which is why it is able to route traffic to and from your other VPN networks and the irb.1 address, but hosts in the subnet will not be able to reach you.

The way to solve this problem is to give your VPN clients a dedicated subnet (as you were trying) and make that route available over your other VPNs.

NATting your VPN clients to an address in the subnet might also work, but it would depend on your topology - traffic from the dynamic-vpn may not be classified correctly by source IP address when traversing zones, and I seem to recall that policy-based NAT was deprecated a while ago on the SRX.

  • Could you explain more of what you mean by "it's not bridged into the existing subnet hanging off irb.1"? I'd given your solutions a thought already but I thought I was missing something fundamental. Marc suggested ARP and JuneOS does offer a proxy-ARP configuration. I haven't had success yet but I'm going to mess with it a little bit more. If not, I'll just apply static routes to my VPN's.
    – patterned
    Mar 1, 2019 at 0:57
  • The best way to think about it is that the VPN tunnel is a separate point-to-point link to your VPN client, so if you're assigning an IP address to the client from a range that is already in use on irb.1, then you're going to have routing issues (eg: you have a duplicate route). Proxy-ARP might work (as long as it's in unrestricted mode), but it's a bit of a hack Mar 1, 2019 at 1:01
  • Ah I guess that makes sense. I guess what I don't understand is how the route works from another VPN. I would think that it would die at irb.0. The routing table shows > via irb.0. NAT is not applied to the VPNs so why is the juniper handling the address differently when the response comes from another subnet? Unless the response is never sent because it's never reaching the destination...
    – patterned
    Mar 1, 2019 at 2:29
  • Yeah, I must admit that had me scratching my head too. Only guessing here, but If you're pinging from the VPN client to the far-end P2P VPN, the SRX may just be returning traffic based on the established session, rather than doing any route return route lookup. Mar 4, 2019 at 5:14
  • You must be right. I guess I won't know unless I had access to ask a dev. I'll just leave it at this and put some static routes on my other VPNs, and divvy out a different subnet to the dyn-vpn. Thanks for your time Benjamin.
    – patterned
    Mar 4, 2019 at 14:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.