Trying to MIP external IP to RRAS (internal)

I am trying to MIP an external IP address to a RRAS server internally

I have created the MIP, and I have also (for testing purposes only initially) created an Allow All ACL through the Firewall to the RRAS server


The MIP works, but im thinking its failing on starting up the IP Protocol 47 session.

When clients connect, it hangs at the "Checking username/password"
LVL 5
cammjAsked:
Who is Participating?
 
cammjAuthor Commented:
I managed to get this working but im not sure what i did
0
 
JFrederick29Commented:
Do you have a second public/external IP address to use for the RRAS server? a 1-1 NAT fixes the GRE (IP 47) issue...
0
 
dpk_walCommented:
Can you post a sanitized configuration of the unit; remove two octets of the public IP addresses; remove all username/password and even hashes.

If you have configured MIP; and have configure any service, something like below:

set interface <int-name> mip <mip-ip> host <host-ip> netmask <netmask> vrouter <vrouter-name>
set policy id x from untrust to trust any mip-name any permit

then everything should be allowed from internet to the internal machine.

Please update.

Thank you.
0
How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

 
cammjAuthor Commented:
Hi JFrederick, Im new to the "Juniper" concept too.. Basically a cisco NAT is a Juniper MIP, where a cisco VIP is a cisco PAT. So yes, its already set up for a one to one basically.

dpk_wal:
set interface "ethernet0/2" mip xxx.xxx.xxx.xxx host 192.168.141.102 netmask 255.255.255.255 vr "trust-vr"

set policy id 215 from "Untrust" to "Trust"  "Any" "MIP(150.101.72.233)" "ANY" permit
set policy id 215
0
 
dpk_walCommented:
By default SSG 140 has ethernet 0/0 as the untrust interface; so I am assuming you have changed that and have cnofigured ethernet0/2 to act as untrust interface, right?

Just wanted to make sure we are not adding MIP on the internal interface rather than on the external interface.

In the above policy command set log as well; and then using webUI or "get log" CLI, see if you get any traffic which matches the policy.

Is it fine to post some basic sanitized config of the box if not all.

Thank you.
0
 
cammjAuthor Commented:
set interface "ethernet0/0" zone "Trust"
set interface "ethernet0/1" zone "DMZ"
set interface "ethernet0/2" zone "Untrust"
0
 
cammjAuthor Commented:
This is very weird, according to the SSG140 the GRE connection is being established. I enabled the log as you asked and this is the output

Date/Time        Source Address/Port        Destination Address/Port        Translated Source Address/Port        Translated Destination Address/Port        Service        Duration        Bytes Sent        Bytes Received        Close Reason
2008-10-04 16:33:11      x.x.76.132:1041      x.x.72.233:1723      x.x.76.132:1041      192.168.141.102:1723      PPTP      126 sec.      1026774      644382      Close - TCP FIN

2008-10-04 16:31:06      x.x.76.132:2048      x.x.72.233:2048      x.x.76.132:2048      192.168.141.102:2048      GRE      0 sec.      0      0      Creation

2008-10-04 16:31:05      x.x.76.132:1041      x.x.72.233:1723      x.x.76.132:1041      192.168.141.102:1723      PPTP      0 sec.      0      0      Creation
0
 
dpk_walCommented:
Hmm can you establish VPN to the server internally; may be the server has personal firewall turned on; or some other configuration parameter which needs some tweaking.

Please advice.

Thank you.
0
 
cammjAuthor Commented:
Yeh I can from the internal network!
0
 
dpk_walCommented:
The logs indicate that the connection is going through the firewall; does the server have the SSG trust IP as its default gateway and no other gateway defined.

Thank you.
0
 
cammjAuthor Commented:
Correct. Only one gw is specified on the server and it's the IP of the trust interface on the SSG140
0
 
cammjAuthor Commented:
I found this which looks awfully like my case but I cant seem to get any sense out of it

http://kb.juniper.net/KB6611
0
 
dpk_walCommented:
Which SOS version are you using; I am using 6.0 and fixed port settings are not available to me.
0
 
cammjAuthor Commented:
5.0r4
0
 
dpk_walCommented:
Hi there; tomorrow is holiday for us and I need some time to search this; not able to put a finger on dip-id 2 [it appears that dip-id 0-3 are reserved; user can specify id from 4-255]; would check with friends at work day after tomorrow. Also, the article you pointed out appears to be obsolete with respect to the latest SOS.

Thank you.
0
 
dpk_walCommented:
In SOS 5.4 PPTP alg is not available; is it possible for you to upgrade to version 6.x [6.1 is the latest available version]; also have a look at the article below:
http://kb.juniper.net/KB12423 

If you can check if the following CLI works:
set alg pptp enable
'and if it makes any difference.

Please update.

Thank you.
0
 
cammjAuthor Commented:
Unfortunately

SSG140-> set alg ?
h323                 H.323 ALG information
mgcp                 MGCP ALG
msrpc                attach ms-rpc alg
rtsp                 attach rtsp rpc alg
sccp                 SCCP ALG information
sip                  SIP ALG
sql                  SQL ALG information
sunrpc               attach sun-rpc alg
SSG140-> set alg

0
 
iw0kCommented:
Hello,

It would be quite usefull to have more information about your configuration :
    -  Your vrouters tables
    -  Your interfaces informations (fake the WAN ip address if you need to hide the information).
    -  Your MIP Policy
On your lan side, the ipconfig of your RRAS server (specially to check the gateway).
Did you try to map the MIP to anything else such as a web server and try to connect to the http from a remote location ?
0
 
dpk_walCommented:
How about upgrading to version 6.1. Do you have a current support contract with Juniper. Do you have access to Juniper website.

Thank you.
0
 
cammjAuthor Commented:
Our support agreement has expired. So I'm not sure if we are entitled to this update.

SSG140-> get vrouter
* indicates default vrouter
A - AutoExport, R - RIP, O - OSPF, B - BGP, P - PIM

   ID Name            Vsys            Owner     Routes    MRoutes     Flags
    1 untrust-vr      Root            shared      0/max       0/max      
*   2 trust-vr        Root            shared     10/max       0/max      

total 2 vrouters shown and 0 of them defined by user
SSG140->

SSG140-> get interface

A - Active, I - Inactive, U - Up, D - Down, R - Ready

Interfaces in vsys Root:
Name           IP Address         Zone        MAC            VLAN State VSD      
eth0/0         192.168.141.253/24 Trust       0019.e242.5c00    -   U   -  
eth0/1         0.0.0.0/0          DMZ         0019.e242.5c05    -   D   -  
eth0/2         x.x.x.x/28  Untrust     0019.e242.5c06    -   U   -  
eth0/3         0.0.0.0/0          Null        0019.e242.5c07    -   D   -  
eth0/4         0.0.0.0/0          Null        0019.e242.5c08    -   D   -  
eth0/5         0.0.0.0/0          Null        0019.e242.5c09    -   D   -  
eth0/6         0.0.0.0/0          Null        0019.e242.5c0a    -   D   -  
eth0/7         0.0.0.0/0          Null        0019.e242.5c0b    -   D   -  
eth0/8         0.0.0.0/0          Null        0019.e242.5c0c    -   D   -  
eth0/9         0.0.0.0/0          Null        0019.e242.5c0d    -   D   -  
tun.1          unnumbered         Trust       ethernet0/0       -   D   -  
tun.2          unnumbered         Untrust     ethernet0/2       -   D   -  
vlan1          0.0.0.0/0          VLAN        0019.e242.5c0f    1   D   -  
null           0.0.0.0/0          Null        N/A               -   U   0  
SSG140->

MIP policy is above.

0
 
dpk_walCommented:
Can you try the CLI as per the document you have posted:

set pol id 215 from untrust to trust any MIP(x.x.x.x) any nat dip-id 2 fix-port permit

and see if it makes any difference [dip-id 2 is system defined and is used for interface dip]. I think this CLI might get the things to work.

PPTP implementation in SOS is really fixed in version 6.1 and it was flawed in earlier releases.

Thank you.
0
 
cammjAuthor Commented:
I'll try that again tonight (in a couple of hours) when business hours are over. Cheers.
0
 
cammjAuthor Commented:
I can confirm that
"set pol id 215 from untrust to trust any MIP(x.x.x.x) any nat dip-id 2 fix-port permit"

Does not work
0
 
dpk_walCommented:
I am not sure what else can be tried here; may be some other expert might be able to help further.

Sorry I was not the best of assistance.

Regards.
0
 
cammjAuthor Commented:
Thank you for trying!
0
 
iw0kCommented:
Can you paste the result of get route please ?
0
 
dpk_walCommented:
I just though we can try debug once and see if the firewall is rejecting the packet or changing something; I would suggest you to do this when the traffic on the network is really low.

Please read the article below to enable debug on the firewall:
http://kb.juniper.net/CUSTOMERSERVICE/KB5536

Also, below to enable snoop if debug does not give enough information:
http://kb.juniper.net/CUSTOMERSERVICE/KB5411

Please check if you see any reject by the firewall; or if you see NAT where the ports are being translated; frankly if ports are masqueraded by the firewall PPTP would fail. Firewall should only do IP masquerading and no port masquerading.

IMPORTANT: If you wish to paste the results; please ensure that the information is sanitized!

Thank you.
0
 
cammjAuthor Commented:
I did try this before (as posted above) and the GRE connection is being established!!
0
 
dpk_walCommented:
I thought you only enabled logging; because with debug you get details about NAT being applied the source/destination VR, zone and interface; policy which was used to dispose the packet among many other details.

Thank you.
0
 
cammjAuthor Commented:
This is still an issue.. My firmware is now Firmware Version:
      6.1.0r5.0 (Firewall+VPN)
0
 
dpk_walCommented:
Are you still getting same debug logs as earlier; can you please post few sanitized debug logs for troubleshooting.

Thank you.
0
 
cammjAuthor Commented:
It appears as if GRE is not being forwarded. Ive loaded pptpsrv and pptclient which are both test applications on to the server and on the client..

Traffic over port TCP 1723 gets through the router to the pptpsrv
Traffic over port 47 does not

I tried setting up a ff on proto 47, however nothing is logged on the router.
0
 
dpk_walCommented:
Can you post few sanitized configuration lines which would help understand the configuration.

Thank you.
0
 
cammjAuthor Commented:
The GRE packets are now getting through.. It was a client NAT issue.. However it is still hanging at "Verifying username/password". This does not happen when connecting to theVPN from the local network.

I will get the config to you straight away
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.