Link to home
Create AccountLog in
Avatar of LR_Brian
LR_BrianFlag for United States of America

asked on

Juniper SSG 140 DNS/Port Forwarding

Hello Experts,

I am having issues configuring a new Juniper SSG 140 Firewall.

I have two locations connected via an MPLS network - we are not using a VPN.  The Hub location is using a D-LINK DFL-800 and has no issues.  The Node location was using a D-LINK DFL-860 until the License file was corrupted and placed the unit into demonstration mode.  To make a long story short, I purchased a Juniper SSG 140 to replace the D-LINK DFL-860 at the Remote Location.

I have been able to successfully install the Juniper into the Node location network and build the routes that are now allowing traffic to pass to Hub location.  Just a quick overview of the Juniper connections:

0/0 - Trusted - connected to my switch stack
0/1 - DMZ - connected to my Voice VLAN
0/2 - Untrusted - connected to WAN port of my Adtran MPLS router

I have copied all of the old rules from our previous DLINK and created policies on the Juniper that are allowing traffic and pings to flow accross the MPLS both ways.

Now - on to the problem.  My Outlook clients at the Node location cannot connect to the mail server by name located at the Hub; they display Cannot connect to Exchange.  I can telnet to the mail server from the same client by DNS name from the Node location without any problems.

I also use an application that uses services on ports 3600 - 4000.  With the Juniper in place, I am unable to telnet from the Hub location to the application on port 3661 across the MPLS, but I can ping it across the network.

I know this is probably not making sense to anyone who reads this, but as I type it - it makes sense to me.  I will try to clarify the best I can if you have questions.  I will also get a copy of the configuration as soon as possible and post it here so you can see the policies I have created.  Most (if not all) of my policies currently use the ANY services group (which I thought included all ports).

Thanks for reading.
Avatar of dpk_wal
dpk_wal
Flag of India image

Assuming that SSG is in L3 mode; you would need to configure NAT for inbound traffic from hub towards SSG; MIP or DIP.
http://kb.juniper.net/InfoCenter/index?page=content&id=KB11909

For issue that you can connect to mail server from behind SSG on port 25 [SMTP] but not through client; firewall configuration looks OK.
If it is that you can only telnet using name [TCP port 23; telnet]; then ensure that you indeed have allowed SMTP or specific protocol on firewall using policy, something like:
set policy from zone1 to zone1 source destination application nat-options permit

Please check and update.

Thank you.
Avatar of LR_Brian

ASKER

The SSG is using L3.

Is it preferred to use NAT at the Interface, or Policy level?  I just want to unblock/allow use of any ports for my trusted MPLS traffic.  Shouldn't using ANY in the service selection do this?

As far as the SMTP traffic - the remote site Outlook clients will not connect to the Exchange Server at the hub.  I can ping the server by IP address and telnet to it on port 25 by name and IP address.  I'm sure its something to do with this new firewall...
ASKER CERTIFIED SOLUTION
Avatar of dpk_wal
dpk_wal
Flag of India image

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
Here is the config file.

I just need to allow all ports to be accessed for my trusted traffic.
config.txt
From the config:
set policy id 8 from "Trust" to "Untrust"  "Pueblo Network" "Any" "ANY" permit

So all traffic originating in trust with source as "Pueblo Network" and destined to untrust is permitted.

nothing from DMZ is allowed to internet.

Please advice if this is what you wish.

Thank you.
Yes - that is outbound traffic to the WAN.

The DMZ is used as a voice LAN and doesn't need access to the Internet.
I have a wicked amount of illegal pak's on my Trusted Interface...

illegal pak 91323....
Can you give a sanitized rough diagram of your network.
Issue corrected. Device was defaulted to interface NAT instead of Route.