[j-nsp] controlling the source IP for the Dns Proxy feature

[Ben Dale]

I've certainly had no issue with stability using route-based VPN.

As far as multiple subnet (proxy-id / traffic selectors) support, as of 12.1X46-D10 this is now native in Junos - 

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

and is dead simple to configure.

If you're a little gun shy on 12.1X code and are still running old-faithful builds like 11.4RLate, then there are a couple of options:

- If your subnets are contiguous, just widen the mask to include them in a single crypto-map on the Cisco side (even if that means widening the mask a LOT)

- If your subnets are arbitrarily selected from different RFC1918 blocks (DOH!), then create separate P2 bindings for each subnet:

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

just be aware that this will only work if the multiple subnets are on the Cisco side (which seems to be true in your case)

There are a few other hacks out there using FBF as well.  J-NET has some good material:

http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-multiple-proxy-ID-on-route-based-VPN-with-multiple-local/td-p/172002/page/2

Cheers,

Ben

On 16 Oct 2014, at 8:35 am, Andy Litzinger <Andy.Litzinger at theplatform.com> wrote:

> I'd happily use route-based vpns if they are supported in my use case.
> Based on Kbs and internet lore, it seemed policy based was the best bet
> for stability.
> 
> My two tunnel endpoint devices are the SRX and a Cisco ASA.
> On the SRX side I've got a single subnet but on the ASA side I've got two
> subnets.  I would happily use a simple policy on the ASA side like 'permit
> ip any <SRX side IP subnet> <SRX side mask>' if i was confident I wasn't
> going to have squirrely issues with connectivity.
> 
> What do you think?
> 
> -andy
> 
> On 10/15/14 3:22 PM, "Ben Dale" <bdale at comlinx.com.au> wrote:
> 
>> Hi Andy,
>> 
>> I have come across this exact issue using the feature.
>> 
>> There was a good reason why we didn't use default address selection that
>> escapes me just now, but I had a slight advantage in that I was using
>> route-based VPNs, so I was able to number the st0 interface with a /32
>> from the corporate range and source my queries from there.
>> 
>> Unfortunately policy-based VPNs are extremely limiting when it comes to
>> things like this.  I can't think of too many scenarios where I'd even use
>> them any more.  If you don't have too many sites, I'd seriously consider
>> migrating them across.
>> 
>> Cheers,
>> 
>> Ben
>> 
>> On 16 Oct 2014, at 1:28 am, Andy Litzinger
>> <andy.litzinger.lists at gmail.com> wrote:
>> 
>>> Hello,
>>> is anyone out there using the dns-proxy feature for the branch SRX?  Are
>>> there any clever tricks for specifying the source address the SRX uses
>>> to
>>> query name servers?  It does not appear to be a config option.
>>> 
>>> with the default config it appears to use the IP of the outbound
>>> interface.  If I add the config statement 'set system default address
>>> selection' i can influence it to use the lo0.0 address, which can solve
>>> my
>>> issue, but not in a way i prefer.
>>> 
>>> my exact problem is the following:
>>> I have an SRX 220H in a remote office. It has an trust and untrust zone.
>>> users sit on the trust zone and receive dhcp from the SRX and use the
>>> SRX
>>> as their default gateway and dns server.  There is a policy based vpn
>>> that
>>> connects from the untrust zone to our corp HQ.  I have the dns-proxy
>>> config
>>> set up so that if a dns request is going to an intranet zone, e.g.
>>> corp.example.com, then it should use DNS servers that live across the
>>> tunnel in our corp HQ.  If they are looking up anything else, they use
>>> google dns servers.
>>> 
>>> here's the relevant config:
>>> dns-proxy {
>>>   interface {
>>>       <interface facing users>;
>>>   }
>>>   default-domain * {
>>>       forwarders {
>>>           8.8.8.8;
>>>           8.8.4.4;
>>>       }
>>>   }
>>>   default-domain corp.example.com {
>>>       forwarders {
>>>           <corp hq name server1>;
>>>           <corp hq name server 2>;
>>>       }
>>>   }
>>> }
>>> 
>>> the problem is without the 'default address selection' set the SRX
>>> tries to
>>> use the untrust interface IP as the source IP to query our corp HQ name
>>> servers, but the traffic doesn't enter the tunnel because it doesn't
>>> match
>>> the vpn policy.  And I can't change the policy to allow it because the
>>> untrust interface IP is the endpoint of the tunnel.  It looks like the
>>> source zone of the dns query is junos-host- is it possible maybe to set
>>> up
>>> a junos-host zone to untrust zone NAT when going to corp-hq IP space?
>>> 
>>> or is there another clever solution?
>>> 
>>> thanks!
>>> -andy
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
>> 
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>