openvpn client on pf gateway

[krad]

On 4 November 2010 10:15, Samuel Martín Moro <faust64 at gmail.com> wrote:

> Hi,
>
>
> I'm using a FreeBSD-8.1 (RELEASE, amd64) as gateway for my local network.
> And pf as firewall.
>
>
> I'm renting a dedicated box, running openvpn.
> My gateway is configured as a client of this VPN.
> I modified my pf.conf to provide internet to my local network.
> I configured iptables on the VPN server (debian-5) to accept everything,
> and
> redirect what I needed to.
>
> Everything seems to work... except...
>
> How can I redirect a port through the VPN?
> I mean...
> The problem does not seem to come from the VPN server, as I can access my
> local gateway from an external server, through the iptables redirection.
> But, when I try to access a host behind that gateway, it won't connect...
>
>
> Here's the pf.conf:
>
> ext_if="bge0"
> int_if="bge1"
> vpn_if="tun0"
>
> lc = $int_if:network
>  vpn="10.253.254.1"
>  emma="10.242.42.200"
> alpha="10.42.42.42"
> delta="10.42.42.44"
>   xi="10.42.142.44"
>
> set skip     on lo0
> scrub in     on $ext_if all fragment reassemble
> scrub in     on $vpn_if all fragment reassemble
> INTERNETZ
> nat          on $ext_if                 from $lc to any -> ($ext_if)
> nat          on $vpn_if                 from $lc to any -> ($vpn_if)
> rdr          on $ext_if inet proto tcp  from any to ($ext_if) port 1666 ->
> $alpha port 1666
> rdr          on $vpn_if inet proto tcp  from any to ($vpn_if) port 1666 ->
> $alpha port 1666
> rdr          on $ext_if inet proto tcp  from any to ($ext_if) port 1667 ->
> $delta port   22
> rdr          on $vpn_if inet proto tcp  from any to ($vpn_if) port 1667 ->
> $delta port   22
> rdr          on $ext_if inet proto tcp  from any to ($ext_if) port 1668 ->
> $alpha port   22
> rdr          on $vpn_if inet proto tcp  from any to ($vpn_if) port 1668 ->
> $alpha port   22
> rdr          on $ext_if inet proto tcp  from any to ($ext_if) port 1669 ->
> $xi    port   22
> rdr          on $vpn_if inet proto tcp  from any to ($vpn_if) port 1669 ->
> $xi    port   22
> rdr          on $ext_if inet proto tcp  from any to ($ext_if) port 9418 ->
> $xi    port 9418
> rdr          on $vpn_if inet proto tcp  from any to ($vpn_if) port 9418 ->
> $xi    port 9418
> pass  in     on $ext_if inet proto tcp  from any to $ext_if   port 1664
> pass  in     on $vpn_if inet proto tcp  from any to $vpn_if   port 1664
> pass  in     on $int_if inet proto tcp  from any to any
> pass  in     on $int_if inet proto udp  from any to any
> block in log on $ext_if inet proto icmp from any to $ext_if
> block in log on $vpn_if inet proto icmp from any to $vpn_if
>
> every rules for $ext_if is working as expected
> so I copied them, replacing my external interface by the vpn one
> ssh from internet to the gateway (1664) works.
> but accessing a ssh server behind the gateway (say alpha, 1668) does not...
>
>
> What am I doing wrong?
>
>
>
> Regards,
>
> --
> Samuel Martín Moro
> {EPITECH.} tek5
> CamTrace S.A.S
>  (+033) 1 41 38 37 60
>  1 Allée de la Venelle
>  92150 Suresnes
>  FRANCE
>
> "Nobody wants to say how this works.
>  Maybe nobody knows ..."
>                      Xorg.conf(5)
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
>


Im not sure if i understand you correctly but are you trying to forward
ports from your colo rented machine to boxes on your LAN via the openvpn
connection?

If you are and this is where the problem is, you probably need to be natting
on the colo boxes vpn interface (tun0). So you will need some iptables
config. Doing this avoids the asymetric routing and natting issue you will
be getting.

Basically if a packet enters your colo box (dst ip A) from client (B), your
coloe box will forward it down the tunnel to host C on a private ip. This
will respond, and create a packet to goto B. However when this packet will
have a public ip as a destination, so when it hits your pf firewall it will
probably get routed out of the default route, and not the vpn interface. As
its not a tcp syn it will most probably be dropped by pf. However if it isnt
it will be natted to the the public ip of your pf box. This is a problem as
this source address isnt the same as the destination address of the initial
packet generated by the client B. Therefore when it actually get to the
client it will just be dropped

Natting on the colo boxes vpn interface sorts all this out for you