PPTP NAT behind SRX

In this post I will try to show how I configured an SRX NAT device to forward PPTP connection.
Please read the entire post without applying any configuration as the first part of this post
does contain some mistakes:)

srx-pptp-nat

As you can see in the topology for this, I have used my SRX device (SRX100 12.1X44-D20.3)
in between an XP VPN client and a RRAS server on Windows2008. I must admit that it
was a pain to install/configure RRAS on 2008 server. After I disabled IPV6, everything
messed up and I had to remove/install interfaces again.

A PPTP connection requires two things;

1) TCP port 1723 for control path
2) GRE for data path

First I configured Static NAT as follows;

[edit]
root@srx100-1# show security nat static 
rule-set ras_gre {
    from zone srx100-wan;
    rule ras_gre_nat {
        match {
            destination-address 192.168.2.101/32;
        }
        then {
            static-nat {
                prefix {
                    172.16.31.4/32;
                }
            }
        }
    }
}

First I was trying to manage this without a static nat. Then I noticed that it is impossible because
of GRE. There is no port that I can translate because of which I needed translation at IP level.
192.168.2.100 is my primary IP on fe-0/0/0.0 interface. For this to work I needed an extra IP
192.168.2.101 to which I create the VPN connection.

And I allowed GRE protocol (protocol number 47) and PPTP (junos-pptp TCP 1723)
in security policy.

[edit]
root@srx100-1# show security policies from-zone srx100-wan to-zone secure_zone 
policy allow-pptp {
    match {
        source-address any;
        destination-address any;
        application [ junos-gre junos-pptp ];
    }
    then {
        permit;
    }
}

ANY-ANY rule is just to make things easier for the test. It can be more specific.

Once this config is committed, I initiated connection from XP (192.168.2.4)
by using built-in XP connection software towards 192.168.2.101 (NAT IP of SRX)
and I could successfully logged in to RAS and received an IP.

Following is the session table for this destination once the connection is
established.

root@srx100-1# run show security flow session destination-prefix 192.168.2.101 
Session ID: 2697, Policy name: allow-pptp/34, Timeout: 1798, Valid
Resource information : PPTP ALG, 1, 2
  In: 192.168.2.4/0 --> 192.168.2.101/46142;gre, If: fe-0/0/0.0, Pkts: 43, Bytes: 4536
  Out: 172.16.31.4/46142 --> 192.168.2.4/65001;gre, If: vlan.1001, Pkts: 0, Bytes: 0

Session ID: 2784, Policy name: allow-pptp/34, Timeout: 1788, Valid
Resource information : PPTP ALG, 1, 0
  In: 192.168.2.4/4547 --> 192.168.2.101/1723;tcp, If: fe-0/0/0.0, Pkts: 6, Bytes: 620
  Out: 172.16.31.4/1723 --> 192.168.2.4/4547;tcp, If: vlan.1001, Pkts: 5, Bytes: 416
Total sessions: 2

I have just tested this PPTP connection in SRX. I really don’t want to
mess with this RRAS server as it flipped me out:)

WARNING:\\

After writing this post, I noticed that this config causes a huge security issue as
we allow all GRE protocol in which any malicious packet can be carried. To prevent this
we have to use PPTP ALG as far as I can see.

For this to work, create security policy only to allow PPTP;

root@srx100-1> show configuration security policies from-zone srx100-wan to-zone secure_zone 
policy allow-pptp {
    match {
        source-address any;
        destination-address any;
        application junos-pptp;
    }
    then {
        permit;
    }
}

You can be more specific here in destination-address indeed.

Then create a destination nat (you don’t have to do static nat in this setup)

rule ras_1723 {
    match {
        source-address 0.0.0.0/0;
        destination-address 192.168.2.100/32;
        destination-port 1723;
    }
    then {
        destination-nat pool ras_server;
    }
}

An after a successful connection, you will see the following sessions.
ALG intercepts TCP 1723 connection and open pinholes for the required GRE
tunnels in both direction. That is why you will see packet counters incrementing
only in one direction.

root@srx100-1> show security flow session protocol gre                                          
Session ID: 7087, Policy name: allow-pptp/46, Timeout: 1796, Valid
Resource information : PPTP ALG, 1, 2
  In: 192.168.2.4/0 --> 192.168.2.100/22135;gre, If: fe-0/0/0.0, Pkts: 179, Bytes: 19945
  Out: 172.16.31.4/22135 --> 192.168.2.4/65001;gre, If: vlan.1001, Pkts: 0, Bytes: 0

Session ID: 7088, Policy name: allow-pptp/46, Timeout: 1788, Valid
Resource information : PPTP ALG, 1, 1
  In: 172.16.31.4/0 --> 192.168.2.4/65002;gre, If: vlan.1001, Pkts: 28, Bytes: 2057
  Out: 192.168.2.4/0 --> 192.168.2.100/65000;gre, If: fe-0/0/0.0, Pkts: 0, Bytes: 0
Total sessions: 2

root@srx100-1> show security flow session destination-port 1723                        
Session ID: 7086, Policy name: allow-pptp/46, Timeout: 1770, Valid
Resource information : PPTP ALG, 1, 0
  In: 192.168.2.4/4136 --> 192.168.2.100/1723;tcp, If: fe-0/0/0.0, Pkts: 16, Bytes: 1100
  Out: 172.16.31.4/1723 --> 192.168.2.4/4136;tcp, If: vlan.1001, Pkts: 10, Bytes: 716
Total sessions: 1
Tags:

About: rtoodtoo

Worked for more than 10 years as a Network/Support Engineer and also interested in Python, Linux, Security and SD-WAN, currently living in the Netherlands and works as a Network Support Engineer. // JNCIE-SEC #223 / RHCE / PCNSE


7 thoughts on “PPTP NAT behind SRX”

  1. Hi.
    >or this to work I needed an extra IP 192.168.2.101 to which I create the VPN connection.

    Why do I need extra IP address? Why can I not use same ip-address for NAT that already has ge-0/0/0? It’s clear for me.

      1. Hi,
        If you use the destination nat instead of static nat which I mentioned at the end, you don’t have to use another IP. Because my box had already one IP with bunch of nat rules, probably I wanted to use another IP to make it clear.

  2. Some points are not clear for me 🙂
    I created DST NAT like this

    nat {
    destination {
    pool MS-RAS-SRV {
    address 10.1.0.10/32 port 1723;
    }
    rule-set ALLOW-PPTP {
    from zone untrust;
    rule PERMIT {
    match {
    source-address 0.0.0.0/0;
    destination-address X.Y.Z.226/32;
    destination-port 1723;
    }
    then {
    destination-nat pool MS-RAS-SRV;
    }
    }
    }
    }
    }

    But when I try to check a session flow I can not see anything:

    admin@r1# run show security flow session destination-port 1723
    Total sessions: 0

    [edit]
    admin@r1#

    Where is my issue?

  3. Hi Admin,
    you are right about that warning, I tested it myself with high-end SRX. Just by opening 1723, GRE is established with ALG.

    Thanks fo ryour post.

    Regards, Milan

Leave a Reply to siteadmin Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.