reply-to and GRE-protocol

J

Jeque

Hello.
I use PF on my FreeBSD gateway. There is the connection diagram:
lay2.jpg


A part of my pf.conf:
Code: 
...
rdr on $ext_if_1 proto tcp from any to $ext_if_1 port pptp tag EXT_PPTP_1 -> $vpnsrv port pptp
rdr on $ext_if_2 proto tcp from any to $ext_if_2 port pptp tag EXT_PPTP_2 -> $vpnsrv port pptp
rdr on $ext_if_1 proto gre from any to $ext_if_1 tag EXT_GRE_1 -> $vpnsrv
rdr on $ext_if_2 proto gre from any to $ext_if_2 tag EXT_GRE_2 -> $vpnsrv
...
pass in quick from ($ext_if_1:network) tagged EXT_PPTP_1 keep state
pass in quick reply-to ($ext_if_1 $gw_1) tagged EXT_PPTP_1 keep state
pass in quick from ($ext_if_1:network) tagged EXT_GRE_1 keep state
pass in quick reply-to ($ext_if_1 $gw_1) tagged EXT_GRE_1 keep state

pass in quick from ($ext_if_2:network) tagged EXT_PPTP_2 keep state
pass in quick reply-to ($ext_if_2 $gw_2) tagged EXT_PPTP_2 keep state
pass in quick from ($ext_if_2:network) tagged EXT_GRE_2 keep state
pass in quick reply-to ($ext_if_2 $gw_2) tagged EXT_GRE_2 keep state
...
pass on $dmz_if proto gre from any to any

The problem is: VPN (PPTP) works only through first (primary) ISP. tcpdump shows that GRE traffic returns to the VPN client always through the default gateway. The reply-to directive in the rule
Code: 
pass in quick reply-to ($ext_if_2 $gw_2) tagged EXT_GRE_2 keep state
doesn't work.

I tested rules with SSH:
Code: 
rdr on $ext_if_1 inet proto tcp to ($ext_if_1) port 22222 tag EXT_IF_1 -> $vpnsrv port ssh
rdr on $ext_if_2 inet proto tcp to ($ext_if_2) port 22222 tag EXT_IF_2 -> $vpnsrv port ssh

pass in quick from ($ext_if_1:network) tagged EXT_IF_1
pass in quick reply-to ($ext_if_1 $gw_1) tagged EXT_IF_1
pass in quick from ($ext_if_2:network) tagged EXT_IF_2
pass in quick reply-to ($ext_if_2 $gw_2) tagged EXT_IF_2
This works fine. I can be connected to the VPN server via SSH through both external IPs.

Where is the error in my PF rules? Or maybe the reply-to directive doesn't work with GRE protocol?
 
Two quotations from manuals:
Code: 
reply-to
           The reply-to option is similar to route-to, but routes packets that
           pass in the opposite direction (replies) to the specified inter-
           face.  Opposite direction is only defined in the context of a state
           entry, and [U]reply-to is useful only in rules that create state[/U].  It
           can be used on systems with multiple external connections to route
           all outgoing packets of a connection through the interface the
           incoming connection arrived through (symmetric routing enforce-
           ment).

Code: 
keep state - [U]works with TCP, UDP, and ICMP[/U].

Does it mean that reply-to doesn't work with GRE protocol?
 
As far as I know it's not possible to keep track of different connections of GRE protocol in a stateful manner because it does not have port numbers that could be identified.
 
The OpenBSD gre man page says that in order to use keepalive packets you should not keep state:
Code: 
     Keepalive packets may optionally be sent to the remote endpoint, which
     decapsulates and returns them, allowing tunnel failure to be detected.
     Enable them like this:

           # ifconfig greN keepalive period count

     This will send a keepalive packet every period seconds.  If no response
     is received in count * period seconds, the link is considered down.  To
     return keepalives, the remote host must be configured to forward packets:

           # sysctl net.inet.ip.forwarding=1

     If pf(4) is enabled then it is necessary to add a pass rule specific for
     the keepalive packets.  The rule must use no state because the keepalive
     packet is entering the network stack multiple times.  In most cases the
     following should work:

           pass quick on gre proto gre no state


See http://www.openbsd.org/cgi-bin/man....manpath=OpenBSD+Current&arch=i386&format=html

I only played with gre about 8 years ago so I have no idea if not keeping state would help in your case ;)

BTW according to https://en.wikipedia.org/wiki/Pptp#Security :
PPTP is (as of Oct 2012) considered cryptographically broken and its use is no longer recommended by Microsoft.
Click to expand...
 
What do they recommend now in place of PPTP? Does windows even have a workable VPN solution included now?
 
kpa said:
What do they recommend now in place of PPTP? Does windows even have a workable VPN solution included now?
Click to expand...

Windows has included L2TP/IPsec since at least Windows 2000 from memory. It's what I've been running here for about 6 years now, to an ASA firewall.

No additional VPN client software required.
 
You must log in or register to reply here.
Back
Top