SRX

We have  a SRX240H2 that has a dhcp configuration to allow mobile devices to connect and is routed via independent ISP. Users are able to connect to the SSID and getting ip and DNS provided by SRX however name resolution does not work and they cannot browse and strangely if a user accesses an unsecured webpage the "insecure page" warning appears but upon accepting the risk the webpage does not load. This was working fine and no changes were made to the network. We tried creating new SSID with new vlan and the results are the same. The configuration on another srx works fine.  Here's my dhcp configuration on the srx routing is ok as the users are able to ping eternal ip address.

set system services dhcp pool 192.168.3.0/24 address-range low 192.168.3.5
set system services dhcp pool 192.168.3.0/24 address-range high 192.168.3.250
set system services dhcp pool 192.168.3.0/24 name-server 4.2.2.2
set system services dhcp pool 192.168.3.0/24 name-server 8.8.8.8
set system services dhcp pool 192.168.3.0/24 router 192.168.3.1

set security zones security-zone Mobile interfaces reth1.399 host-inbound-traffic system-services all
set security zones security-zone Mobile interfaces reth1.399 host-inbound-traffic protocols all

I have restarted DHCP services but that didnt help either...

Hi nanu,

DNS resolution is not working for all websites?

Can you ping www.juniper.net from a PC on subnet 192.168.3.X and confirm if a session is created on the SRX:

> show security flow session source-prefix [PC_IP_Address] destination port 53 protocol udp

Note we are looking for DNS session, not the ping session.

Yes DNS is not working for any web resolution

Session ID: 38, Policy name: AMP_Mobile/15, State: Active, Timeout: 56, Valid 

  In: 192.168.3.65/64883 --> 1.1.1.1/53;udp, If: reth1.399, Pkts: 4, Bytes: 244 

  Out: 1.1.1.1/53 --> 192.168.3.65/64883;udp, If: reth0.34, Pkts: 0, Bytes: 0 

Session ID: 250578, Policy name: AMP_Mobile/15, State: Active, Timeout: 18, Valid 

  In: 192.168.3.65/54390 --> 8.8.8.8/53;udp, If: reth1.399, Pkts: 3, Bytes: 186 

  Out: 8.8.8.8/53 --> 192.168.3.65/54390;udp, If: reth0.34, Pkts: 0, Bytes: 0 

Session ID: 250627, Policy name: AMP_Mobile/15, State: Active, Timeout: 18, Valid 

  In: 192.168.3.65/54390 --> 1.1.1.1/53;udp, If: reth1.399, Pkts: 4, Bytes: 248 

  Out: 1.1.1.1/53 --> 192.168.3.65/54390;udp, If: reth0.34, Pkts: 0, Bytes: 0 

Session ID: 252963, Policy name: AMP_Mobile/15, State: Active, Timeout: 56, Valid 

  In: 192.168.3.65/64883 --> 8.8.8.8/53;udp, If: reth1.399, Pkts: 3, Bytes: 183 

  Out: 8.8.8.8/53 --> 192.168.3.65/64883;udp, If: reth0.34, Pkts: 0, Bytes: 0 

I assume based on the description that you have already verified that the mobile clients have those google dns servers as part of the dhcp setup.

I also assume you are checking nslookup on a device to confirm if dns lookups are working and they do not.

Please verify access to those servers from your Mobile zone with both the security policy and nat rule.

If this should allow ping see if the client can ping the ip addresses for the name servers.

Should this not work verify if the session is created on the srx using 

show security flow session destination-prefix 8.8.8.8/32 source-prefix (mobile ip)

This should show the ping and lookup attempts from the device if they are permitted. 

If there are no sessions then the policy is missing.

If there is a session but the nat does not occur than the nat rule is missing.

You can see nat by the change in ip address between the forward and reverse entry on the session log printed.

Hi Steve

NAT is happening as expected and we can ping the ip and the polices are in place, for testing all policies from the mobile zone to untrust is kept as any.

show security flow session source-prefix 192.168.3.65
node0:
--------------------------------------------------------------------------

Session ID: 340, Policy name: Operation/10, State: Active, Timeout: 2, Valid
In: 192.168.3.65/6578 --> 23.220.63.173/1;icmp, Conn Tag: 0x0, If: reth1.34, Pkts: 1, Bytes: 60,
Out: 23.220.63.173/1 --> 1xx.1xx.1xx.1xx/54128;icmp, Conn Tag: 0x0, If: reth0.50, Pkts: 1, Bytes: 60,

Let's have a look at the nat rule details.  This dns session shows no nat is occuring.

Session ID: 252963, Policy name: AMP_Mobile/15, State: Active, Timeout: 56, Valid 

  In: 192.168.3.65/64883 --> 8.8.8.8/53;udp, If: reth1.399, Pkts: 3, Bytes: 183 

  Out: 8.8.8.8/53 --> 192.168.3.65/64883;udp, If: reth0.34, Pkts: 0, Bytes: 0 

While it is successfully occuring on the ping request assuming the anonamized address is your public.

Session ID: 340, Policy name: Operation/10, State: Active, Timeout: 2, Valid
In: 192.168.3.65/6578 --> 23.220.63.173/1;icmp, Conn Tag: 0x0, If: reth1.34, Pkts: 1, Bytes: 60,
Out: 23.220.63.173/1 --> 1xx.1xx.1xx.1xx/54128;icmp, Conn Tag: 0x0, If: reth0.50, Pkts: 1, Bytes: 60,

So we need to determine why those dns request flows do not hit the nat rule.

nanu.

Thanks for providing the output from the DNS sessions.

If the DNS server address 1.1.1.1 is a public address, we can see the SRX is expecting a returing flow from 1.1.1.1 towards 192.168.3.65 which wont be happening unless there is a device infront of the SRX performing some sort of source NAT to the packets sent from the internal hosts to the DNS server on the Internet. A Internet router wont be able to send packets to a private IP address like 192.163.3.65. Is the SRX supposed to perform source NAT to these communications?

Session ID: 38, Policy name: AMP_Mobile/15, State: Active, Timeout: 56, Valid 

  In: 192.168.3.65/64883 --> 1.1.1.1/53;udp, If: reth1.399, Pkts: 4, Bytes: 244 

  Out: 1.1.1.1/53 --> 192.168.3.65/64883;udp, If: reth0.34, Pkts: 0, Bytes: 0 

If the DNS server address (1.1.1.1) is an internal address then we need to confirm why the SRX is not receiving the returning packets. Likely it is not receiving them, however I will advise configuring flow traceoptions just to doublecheck there is not a odd situation (like asymetric routing) causing the SRX to drop these packets.

set security flow traceoptions file FLOW_TRACE
set security flow traceoptions flag basic-datapath
set security flow traceoptions packet-filter TEST source-prefix 192.168.3.65
set security flow traceoptions packet-filter TEST destination-prefix 1.1.1.1
 set security flow traceoptions packet-filter TEST destination-port 53

[commit and check if there are returning packets seen with the following command]

> show log FLOW_TRACE | match matched

The issue was with the block that was blocking access from 192.168 network to the internet and only allowing outbound icmp.

Hello,

This actually rings a bell, or rather quite a few bells 

---

@nanu4u21 wrote:

SRX240H2 that has a dhcp configuration to allow mobile devices to connect and is routed via independent ISP.

What is the MTU across that "independent ISP"? Can You run a ping 8.8.8.8 with 1472 Byte payload and DF bit set across this ISP?

Use a Windows laptop CMD window instead of mobile device to test it.

---

@nanu4u21 wrote:

Users are able to connect to the SSID and getting ip and DNS provided by SRX however name resolution does not work 

 

---

I assume "users" in this context are trying to connect from their mobile devices. Can You check it Windows laptop users have the same issue? Please run "nslookup juniper.net" from a Windows laptop CMD window to see if the most basic name resolution works.

---

@nanu4u21 wrote:

they cannot browse and strangely if a user accesses an unsecured webpage the "insecure page" warning appears but upon accepting the risk the webpage does not load.

---

AFAIK, "insecure page" warning is generated locally in the browser so nothing to do with network.  But inability to open the actual insecure page is usually a MTU problem, see above.

---

@nanu4u21 wrote:

The configuration on another srx works fine. 

---

Is this "another srx" connected to internet via the same "independent ISP"? If yes, can You test with the same mobile device(s) You are using on SRX240H2?

HTH

Thx

Alex

We tested with Laptops connected to the mobile SSID  and same results ping with xx MTU is not an issue, DNS resolution is.  We tested from other SRX that is also connected via same ISP and it works fine.