# reply-to and GRE-protocol



## Jeque (Mar 11, 2013)

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






A part of my pf.conf:

```
...
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 
	
	



```
pass in quick reply-to ($ext_if_2 $gw_2) tagged EXT_GRE_2 keep state
```
 doesn't work.

I tested rules with SSH:

```
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?


----------



## Jeque (Mar 13, 2013)

Two quotations from manuals:

```
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).
```


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

Does it mean that reply-to doesn't work with GRE protocol?


----------



## kpa (Mar 13, 2013)

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.


----------



## J65nko (Mar 13, 2013)

The OpenBSD gre man page says that in order to use keepalive packets you should not keep state:

```
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.


----------



## kpa (Mar 13, 2013)

What do they recommend now in place of PPTP? Does windows even have a workable VPN solution included now?


----------



## throAU (Mar 14, 2013)

kpa said:
			
		

> What do they recommend now in place of PPTP? Does windows even have a workable VPN solution included now?



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.


----------



## Jeque (Mar 14, 2013)

L2TP/IPsec uses ESP protocol. Are you sure that reply-to can route ESP?


----------



## cj (Mar 29, 2013)

Source based routing with multiple gateways may be what your're looking to implement. Check out the link below.


http://www.mmacleod.ca/blog/2011/06/source-based-routing-with-freebsd-using-multiple-routing-table/


----------



## Anonymous (Mar 29, 2013)

Jeque said:
			
		

> L2TP/IPsec uses ESP protocol. Are you sure that reply-to can route ESP?



racoon of security/ipsec-tools can be forced to always use NAT-T, i.e. RFC 3948 - UDP Encapsulation of IPsec ESP Packets.


```
remote anonymous
{
        ...
        nat_traversal    force;
        ...
}
```

In that case the firewall/NAT has to deal with UDP packets on port 4500 only.


----------

