SRX

Hello everyone, I’m trying to configure my srx100 for almost 2 weeks and can’t find solution to my problem. Here is my setup:

BT Openreach modem (BT infinity broadband) -->srx100 -->LAN with 1 physical server and 6 VMs

Have been given block of ip addresses from BT:

• network address: XXX.142.86.40
• router/Hub address: XXX.142.86.46
• subnet mask: 255.255.255.248
• block: xxx.142.86.41 - xxx.142.86.45

Configured public facing interface on srx100 to be xxx.142.86.45/29 and also created nat-src and nat-dest rules. Config file attached.

PROBLEM:

I can access the internet and DNS resolution works fine but I can’t get my ‘incoming services’ to work. I want to be able to connect to one of my internal servers (192.158.1.225) via PPTP but currently am unable to make this work. I need to be able to ‘route my emails to exchange server too but bacuse I can’t connect via VPN I assume that all other forwarded ports are not working. I checked the config hundreds of times and I’m pretty sure that the problem is with nat-dest policy/rule/address pool as I can access the Internet ok from internal network.

Can someone tell me if I assigned the ip addresses to public interface correctly or maybe I messed up something with nat-dest rules.

Also I checked internal RRAS server and I can connect via VPN locally so there is no problem there. Also (you might think its silly but trying everything here), I added two ip addresses for my RRAS server (Dial-up vpn address and interface address) to make sure the problem isn’t with internal server. Checked the logs on my RRAS server hundreds of times and nothing is being logged there when I am trying to connect from another location using xxx.142.86.45 ip address. Logs are not showing anything on my SRX100 so maybe this is something you can help with too. Tried clearing the space on SRX but still nothing being shown in policy log while viewing via web browser.

I have a customer who has very similar infrastructure (also with BT) and this config works for him like a charm for them.

PLEASE HELP! I am pulling my hair out!

Attachment(s)

config.txt   12 KB 1 version

In your DNAT rules you must match with destination-address xxx.142.86.45/32 instead of destination-address xxx.142.86.45/29

--
If this post solves your problem, please mark this post as "Accepted Solution".
Kudos are appreciated

Hi, thanks fo replying. I've done that (I'm sure I've tried that before) and still experiencing the same problem.

I ran 'show security nat destination rull all' command and I can see Translation hits on my 'inbound-pptp' NAT rule but still unable to establish VPN.

Also I tested inboud-ilo rule and this one works fine. I can access ilo interface from internet. I will test inbound-mail rule tonight but so far issue seems to be related to pptp only.

To clarify, now that you have changed the /29 to /32 within the destination NAT rules, all but one of the rules work? So just the PPTP rule not working?

A couple of things you could try.

• when trying to get security related things working in can be helpful to open up the rules a little e.g changing the application on the security policy from 'junos-pptp' to 'any' temporarily.
• PPTP uses an ALG. This is enabled by default and can be checked using 'show security alg status' within operational mode. ALGs can cause issues sometimes so you could disable this with 'set security alg pptp disable' within configuration mode.

Not sure if this is going to help though.

Hi, thanks for replying.

So I tested the incoming-mail destination NAT rule by redirecting my emails to xxx.142.86.45  but it didn't work. When running 'show security nat destination rule all' I can see 'Translation Hits' ans 'successfull sessions' values increasing but no mails are comming through. Same for incomming-pptp rule - 'Translation Hits' ans 'successfull sessions' values increasing but I am unable to establish VPN.

I executed 'show security alg status' and pptp was enabled. Disabled pptp as you advised but issue persist.

Also, yes I changed subnet mask for my NAT destination address from /29 to /32 to mach server subnet

Also tried your suggestion and changed applications to 'all' in POL-PPTP security policy but this also disn't help.

NAT dest working fine by the look of it, it mast be something esle. I still can't see any events within policy logs. Any idea how to enable this functionality please. If the sessions are getting through NAT then the next place to check wold be polices but can't see anything in logs. Is there any way to see policies' log via CLI?

I wonder why incoming-ilo nat works but others don't. The difference between ilo and rest of NAT rules is that ilo interface is on phisical server but rest of my services are on VMs. First thing that comes to mind is that sessions are not being forwarded to these VMs but I can ping all my Virtual Servers from the srx without any problem. It is driving me mad!

Although you are sending events to the control plane from the data plane with the 'security log mode event', you are only logging critical alarms to the messages log file which may explain why you cannot see any logs for the flows. 

#set system syslog file flow-logs any any

#set system syslog file flow-logs match RT_FLOW

You should be able to see the flows in this file using:

>show log flow-logs

I cannot see anything wrong with your configuration and as you say the ILO is working and appears to be configured in the same way as the others.

Just a silly point - As the other devices are on VMs (not something I know much about), they definately have the correct default gateway? I ask as that would explain why the SRX can ping them locally but nothing outside the network can get a response.

Thanks, I can now see the traffic via Cli (still unable to see anything in policy log in web browser though, but this isn't my biggest concern right now).

Yes, DG is exactly the same accross the network (192.168.1.254).

Are you able to configure another network within the trust zone and attempt to use any of the services from that network? It would eliminate the specific security policies and the NAT. That might help to pin-point what is actually causing the problem.

Also here is teh log of events logged when I'm trying to connect:

Nov 23 13:07:11 FW01 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed idle Timeout: yyy.78.47.93/45081->xxx.142.86.45/1723 junos-pptp yyy.78.47.93/45081->192.168.1.225/1723 None inbound-pptp 6 POL-PPTP Internet trust 20294 3(152) 0(0) 20 INCONCLUSIVE INCONCLUSIVE N/A(N/A) pp0.0 UNKNOWN
Nov 23 13:07:11 FW01 RT_FLOW: APPTRACK_SESSION_CLOSE: AppTrack session closed idle Timeout: yyy.78.47.93/45081->xxx.142.86.45/1723 junos-pptp UNKNOWN UNKNOWN yyy.78.47.93/45081->192.168.1.225/1723 None inbound-pptp 6 POL-PPTP Internet trust 20294 3(152) 0(0) 20 N/A N/A No

It looks like the PPTP server is not responding.

Could you check the logs on the server? And maybe run a packet capture on it.

Also make sure you can ping or at least arp the server IP (192.168.1.225) from your SRX device.

I just had Microsoft logged on to my server and investigating as I was almost sure that the problem must be with RRAS server or Hyper-V setup but they brought very interesting point. Theylogged on to remote computer and tried  'telnet xxx.142.86.45 1723' and the port appears closed. I then tried telnetting to two of my other clients networks who has the same srx100 firewall with teh same policies and it worked - I was able to telnet on port 1723 for these two clients.

Microsoft then installed some 3rd party port monitoring tool on my host server and they were able to telnet to my RRAS server. All of these test are evidence that the problem is on the srx rather then anywhere else.

This also means that 'ransmission hits and successfull session values don't mean that traffic is getting through but this means that it is only 'hitting' srx.

Answering pantunes question - there is nothing in logs on the RRAS server whenen trying to accces from the Internet. Events are only being logged when establishing vpn connections locally from LAN clients. 

So the problem is with NAT destination rules or Policies on srx. Anyone?

From the below output you can state the following:

Nov 23 13:07:11 FW01 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed idle Timeout: yyy.78.47.93/45081->yyy.78.47.93/1723 junos-pptp yyy.78.47.93/45081->192.168.1.225/1723 None inbound-pptp 6 POL-PPTP Internet trust 20294 3(152) 0(0) 20 INCONCLUSIVE INCONCLUSIVE N/A(N/A) pp0.0 UNKNOWN

- A TCP flow (IP protocol 6) packet SA=yyy.78.47.93 and DA=yyy.78.47.93 and DP=1723 hit the SRX.

- Ingress security zone=Internet, Egress=trust, ingress interface=pp0.0

- The packets matched the security policy POL-PPTP

- The DA was translated to 192.168.1.225 inbound-pptp

- 3 packets or 152 bytes were received (and forwarded ) on the ingress interface : 3(152)

- For the return traffic 0 packets were received on the Trust interface : 0(0)

- The session lasted 20s : this is the default timeout for an incomplete TCP-handshake

This is why I say that the server might not be responding, or maybe there is a problem between the SRX and the PPTP server. From the SRX, can you ping the server? Can you telnet to 192.168.1.225 port 1723? Can you do a packet capture on the firewall and see the incoming TCP SYN packets? Isn't there any firewall running on the server? 

If the telnet test does work and if you are confident the server is not firewalling some source IP, then, and as someone suggested, you can also try and use a customized application that doesn't use the PPTP  ALG. I am not familiar with this protocol.

Thank you for this anylysis pantunes. 

Yes, I can ping my RRAS server from srx and I can 'telnet 192.168.1.225 1723' locally from my Hyper-V host. Also firewall is disabled on host and RRAS for testing purposes.

I also captured the traffic on srx for 3 minutes while I was trying to connect via VPN from another PC and there was no 'tcp syn' enties in the log whatsoever.

I'll do some research on ALG.

Also I  changed my iLO interface ip address to .11 and waited 30 minutes and I can still access my ilo from the Internet which makes me wonder how long it takes before srx picks up the changes I apply on the network. I tested many different vriations of settings but If I have to wait 1 hour or restart srx after each change then I have do this all over again.

Might be silly question but can this behaviour be caused by a network switch? This is the only thing between srx and the server. Port configuration/incorrect frame size/port speed?

I am not sure if you tried to telnet to the PPTP server port 1723 (telnet 192.168.1.225 port 1723) from the SRX.

If you are able then the issue may be with the PPTP ALG on the firewall.

I you aren't then the issue may be between the SRX and the PPTP server

No, I can't. It is timing out.

Installed Wireshark and capturing the traffic. Don't know much about it so it might take a while to get through the log and understand something from it but will give it a try.

As far as I understood, from the SRX:

- you can ping the server : ping 192.168.1.225

- you cannot telnet to the server: telnet 192.168.1.225 port 1723

Is the service really running on port 1723 on the server? Can you run netstat -ln and see the port 1723 open on the server?

Are you confident that there is no firewall on the server?

Hi Pantunes, thank you for being so patient wth this issue.

I haven't found anything helpful in wireshark log (most likely due to my unfamiliarity with this program). Before I contacted Microsoft first time  I was certain that the issue is somewhere between physical host and virtual servers but they managed to convince me that I was wrong. They said that beacuse they are unable to telnet on port 1723 from outsite it means that the port is closed on the firewall but this is incorrect. If the port is closed on the destination server the telnet wouldn't work even if the firewall is configured correctly. So I decided to install RRAS server on phisical host and see if I can then connect via telnet. I was right - after installing RRAS on physical host (and changing the nat pool address/policy address on the firewall to point to physical host ip address) I managed to establish telnet connection on port 1723 to my physical host from outside.

So I then called Microsoft and advised that this is an evidence that the problem is between physical server and VMs. They logged on remotely again and were investigating for almost 2 hours but only thing they were doing was changing the authentication methods and allowed protecols within RRAS configuration options. I talked to them and said that I was doing the same for almost a week and that they are waisting their time as RRAS server and port 1723 is not the only port affected and that I am also unable to telnet on port 22 to my exchange server which is also a virtual machine.

The engineer then put me on hold and had a conversation with someone (most likely more senior Engineer). After 20 minutes he said that I will have to uninstall Symantec Endpoint Protection from both physical and Virtual servers using cleanwipe and then to call them back. I couldn't see a point in doing this as SEP was already disabled on all the machines. I'm sure that he only asked me to do this to buy more time but I did that anyway and guess what!? It worked!

The SEP installed on the phisical host was causing the problem. It was disabled the whole time hence I didn't even think about uninstalling it. 

I can easily say that that was most frustrating problem I was dealing with in my 8 years in IT. It all make sense now as this was the only thing between phisical host and VMs. Why SEP keeps ports closed even if you disable the program that another mistery.

If you are facing any Host-->VM communication issues make sure SEP is unsintalled using cleanwipe. Aparrently uninstalling SEP from Programs and Features isn't enough and this can leave some sep stuff behind.

Thank you all for your input but most importantly Pantunes. In your last reply you asked about firewall which was the real source of the problem! I'm sure that someone mentioned firewall before but I really cound see a point of uninstalling it if it was already disabled. It simply doesn't make sense.