3

Multiple VPNs setup with a Juniper SRX320.

The SRX320 has an irb interface as follows:

  irb {
    unit 0 {
        family inet {
            address 192.168.120.1/24;
        }
    }
}

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 {
            network 192.168.120.0/24;
            dhcp-attributes {
                name-server {
                    192.168.120.15;
                }
                router {
                    192.168.120.1;
                }
            }

Remote resources are defined here:

dynamic-vpn {
    access-profile dyn-vpn;
    clients {
        all {
            remote-protected-resources {
                192.168.0.0/16;
            }
    ...
    ...

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 192.168.120.1
  • I CANNOT ping any other 192.168.120.0/24 address (like the name server, or the DC, or anything else.
  • I can hit everything else inside 192.168.0.0/16 (the other VPNs, for instance 192.168.150.1)

If I change my pool assignment to a new pool and assign it to 192.168.121.252/30, I can ping everything within 192.168.120.0 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 at 10:45
  • All the devices I want to hit are assigned addresses in the 192.168.120.0/24 block. I would assume they have a route to me, right? Their default gateway is 192.168.120.1 – patterned Feb 23 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. – Marc 'netztier' Luethi Feb 27 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 at 12:52
  • Do other devices in 192.168.120.0/24 have ARP resolution for the 192.168.120.x assigned to the connected clients? If hosts on 192.168.120.0/24 want to talk (or respond) to any device in 192.168.120.0/24, 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... – Marc 'netztier' Luethi Feb 27 at 16:31
2
+50

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 192.168.120.0/24 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 192.168.120.0/24 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 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 – Benjamin Dale Mar 1 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 192.168.120.0/24 > 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 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. – Benjamin Dale Mar 4 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 at 14:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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