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

[Andy Litzinger]

I'm running 12.1X44-D40.2 right now (had to run newer 12.1X code to even
use the dns-proxy feature :) ).  I'll give X46-D10 a look; the
traffic-selctors looks pretty interesting.

As far as your comment regarding widening the crypto-map- that's what i
was implying with my example acl- basically widening it on the cisco side
to include every IP subnet ('any').  Not sure if that's allowed.

Either way it looks like i've got some good options to try.

Thank you!
 -andy

On 10/15/14 3:50 PM, "Ben Dale" <bdale at comlinx.com.au> wrote:

>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
>> 
>