PPTP: Am I blocking access?

GlueGuy · Wed Jun 08, 2011 9:38 pm

I've set up a PPTP tunnel, and it works up to a point.

I am able to ping every device on the subnet, but I am not able to access the router through a local IP (e.g. Winbox). So I figure I am blocking something in the firewall, or I need a proxy ARP or something to get two-way communications actually working. Do I need to change or add firewall rules? Here are the firewall rules so far

[admin@XXXX Router] /ip firewall filter> print chain=input
Flags: X - disabled, I - invalid, D - dynamic 
 0   ;;; Drop invalid connections
     chain=input action=drop connection-state=invalid 

 1   ;;; Allow established connections
     chain=input action=accept connection-state=established 

 2   ;;; Allow related connections
     chain=input action=accept connection-state=related 

 3   ;;; Allow UDP
     chain=input action=accept protocol=udp 

 4   ;;; Allow ICMP
     chain=input action=accept protocol=icmp 

 5   ;;; Allow incoming on the BACnet port
     chain=input action=accept protocol=udp in-interface=ether1 dst-port=47808 

 6   ;;; Web server access for Fred's web server
     chain=input action=accept protocol=tcp in-interface=ether1 dst-port=47080 

 7   ;;; Allow incoming for PPTP tunnel
     chain=input action=accept protocol=tcp dst-port=1723 

 8   ;;; Allow GRE (protocol 47) for PPTP tunnel
     chain=input action=accept protocol=gre 

 9   ;;; Allow input from the NOC private address space
     chain=input action=accept src-address-list=NOCprivate 

10 X ;;; Log everything about to be dropped
     chain=input action=log log-prefix="Drop" 

11   ;;; Drop everything else
     chain=input action=drop

fewi · Wed Jun 08, 2011 9:54 pm

Add the IP space on your side of the PPTP tunnel to the "NOCprivate" address list. That should suffice.

GlueGuy · Wed Jun 08, 2011 9:58 pm

It appears that I am blocking it. When I enable the firewall rule to print packets about to be dropped, I get this:

11:51:32 firewall,info Drop input: in:pptp-in1 out:(none), proto TCP (SYN), 172.16.1.198:56043->172.16.1.1:8291, len 32

I do have port 8291 enabled for services (see below). Do I need to add another rule to accept from pptp-in? I thought the "related" rule on the input chain would have let this through?

[admin@XXX Router] /ip service> print
Flags: X - disabled, I - invalid 
 #   NAME                                      PORT  ADDRESS            CERTIFICATE                                    
 0 X telnet                                    23    0.0.0.0/0         
 1 X ftp                                       21    0.0.0.0/0         
 2 X www                                       80    0.0.0.0/0         
 3   ssh                                       22    0.0.0.0/0         
 4 X www-ssl                                   443   0.0.0.0/0          none                                           
 5   api                                       8728  0.0.0.0/0         
 6   winbox                                    8291  0.0.0.0/0

GlueGuy · Wed Jun 08, 2011 10:06 pm

I think I fixed it by allowing packets from pptp-in thusly (right after the gre rule):

 9   ;;; Allow incoming from the pptp-in port
     chain=input action=accept in-interface=pptp-in1

Although it's not entirely clear to me why I needed to do this.

fewi · Wed Jun 08, 2011 10:07 pm

Related traffic is traffic found by firewall inspection helpers. For example, you open up an FTP control channel and start downloading a file. That dynamically negotiates a data channel through which to transfer the file. The firewall helper inspects the control channel and finds the data channel being negotiated, and classifies that data channel as related and can then permit it regardless of the ports used for it.
A connection state of established allows through packets in connections where the initial packet was permitted by a different rule so the connection could establish in the first place.

Winbox runs over TCP/8291. There is only one rule in your config that could do this:

9   ;;; Allow input from the NOC private address space
     chain=input action=accept src-address-list=NOCprivate

So add the IPs you're coming from to that address list and you'll be up and running, and you can stop allowing traffic entering the router through the PPTP interface as you did in the rule you added.

You may want to consult the packet flow diagram.

GlueGuy · Thu Jun 09, 2011 10:09 pm

I think I get it. Since the packets "coming in" were actually on a dynamic "internal" port, I decided to fix this by just allowing incoming traffic from any local port (AKA not the WAN port) which on this router is ether1. The rules now go like this:

[admin@XXXX Router] /ip firewall filter> print chain=input
Flags: X - disabled, I - invalid, D - dynamic 
 0   ;;; Drop invalid connections
     chain=input action=drop connection-state=invalid 

 1   ;;; Allow established connections
     chain=input action=accept connection-state=established 

 2   ;;; Allow related connections
     chain=input action=accept connection-state=related 

 3   ;;; Allow UDP
     chain=input action=accept protocol=udp 

 4   ;;; Allow ICMP
     chain=input action=accept protocol=icmp 

 5   ;;; Allow incoming from anything _BUT_ the WAN port (AKA local and tunnels)
     chain=input action=accept in-interface=!ether1 

 6   ;;; Allow incoming on the BACnet port
     chain=input action=accept protocol=udp in-interface=ether1 dst-port=47808 

 7   ;;; Web server access for Fred's web server
     chain=input action=accept protocol=tcp in-interface=ether1 dst-port=47080 

 8   ;;; Allow incoming for PPTP tunnel
     chain=input action=accept protocol=tcp dst-port=1723 

 9   ;;; Allow GRE (protocol 47) for PPTP tunnel
     chain=input action=accept protocol=gre 

10   ;;; Allow input from the NOC private address space
     chain=input action=accept src-address-list=NOCprivate 

11 X ;;; Log everything about to be dropped
     chain=input action=log log-prefix="Drop" 

12   ;;; Drop everything else
     chain=input action=drop

I added the LAN addresses to the NOCprivate list, but that rule (rule 10) does not trigger. Instead, it's now accepted on rule #5 (!ether1).

fewi · Thu Jun 09, 2011 10:14 pm

I added the LAN addresses to the NOCprivate list, but that rule (rule 10) does not trigger. Instead, it's now accepted on rule #5 (!ether1).

Yes, because it fits that rule and that rule comes first.
If you're cool with everyone have unequivocal access unless they're coming from the WAN that's an elegant and simple solution. You could get rid of rule number 10 at that point, presumably no address on the NOCprivate address is situated behind the ether1 interface, so nothing would ever match that rule (everything would get caught by rule 5 instead).

GlueGuy · Fri Jun 10, 2011 5:13 am

Thanks for the sanity check fewi. It's great to have someone like you to bounce these things off of.

We leave rule 10 in place because we have a very small number of private IPs we use at the NOC that actually do come in from the WAN side. Kind of our back(or is it front?) door.

The customer does not have the expertise to manage their own router, so we do this to simplify our (and hopefully their) life.

PPTP: Am I blocking access?

PPTP: Am I blocking access?

Re: PPTP: Am I blocking access?

Re: PPTP: Am I blocking access?

Re: PPTP: Am I blocking access?

Re: PPTP: Am I blocking access?

Re: PPTP: Am I blocking access?

Re: PPTP: Am I blocking access?

Re: PPTP: Am I blocking access?

Who is online