[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: optimizing pf firewall



On Thu, Oct 06, 2005 at 03:48:17PM -0400, Dave wrote:
>    My second problem, i'm trying to do mpd vpn, which relies on gre. I've 
> got a natted vpn server at 192.168.1.3 but when an external connection 
> happens, that is one outside my firewall from a windows box i get an error 
> 619, which after googling and asking, have determined that gre isn't 
> natting to the box. Does anyone have this working?
1)
meaning is anyone successfully natting on gre iface?
i am.
in order to allow BGP to function over the VPN group i'm in, we've
setup gre ifaces that ride on the IPsec tunnel.  IPsec establishes
ESP flows from one /32 to another, and then we put the GRE ifaces
riding on those /32s ( the GREs have their own /32s also ).  then
we run BGP peering between those GRE /32s, and advertise the normal
lan subnets.
on my endpoint, i run nat on the GRE iface if the destination is 
an IP i've learned via BGP, and the source is the IP of the 
GRE iface in question, rewriting the source to be the IP of the LAN
iface of the endpoint.
---
i =                     sis0
table   <HK4801VPN>     persist         { 172.17.7.0/24 172.18.7.0/24 }
table   <bgp_p54c>      persist         { }
table   <bgp_ub3rgeek>  persist         { }
table   <bgp_commodore> persist         { }
nat on gre inet from <HK4801VPN> to { <bgp_p54c> <bgp_ub3rgeek> <bgp_commodore> } -> ($i:0)
---
those bgp tables are populated with 'set pftable blahblah' in bgpd.conf; i use
a different table for each peer (even tho they ultimately usually have
the same IPs in them) after noticing that if peer A has a valid route to subnet X,
populates the table, and then peerB has a valid route to subnet X, but then loses
the route to subnet X, bgpd removes subnet X from the table regardless of whether
peer A has a valid route to it or not.
without this nat line, traffic leaves my endpoint's gre iface as being from the 172.1[78].7.???
IP of the gre iface, if destined for any host in a remote subnet; which is not 
necessarily chill since only the actual VPN endpoints should be using those IPs
( per our policy ).  a default route on a remote LAN host would work if it also 
happens to point to that remote subnet's endpoint, but it's crappy because of
having to put more IPs in more configs.
---- anyway , that's all probably unrelated to your scenario ----
or
2)
you say 'gre isn't natting to the box', so do you mean that outgoing traffic
is not having its source address rewritten, or that incoming is not having
its destination address rewritten?  literally, those are both "translating"
"network addresses", but in the scope of pf, nat==outgoing, rdr==incoming.
is the gre iface actually on the obsdbox, or are the gre-proto packets
supposed to traverse the bsd box and be decapsulated by the host on the LAN ?
if the latter, i think maybe you will be successful with either a
rdr or binat ( binat groks proto and src/dest addrs, just not ports )
  jared
-- 
[ openbsd 3.8 GENERIC ( sep 27 ) // i386 ]