[ale] Iptables with vpn

Jim Kinney jim.kinney at gmail.com
Thu Oct 16 08:03:01 EDT 2008


And this will be an ALE presentation....?

Good work!

On Wed, Oct 15, 2008 at 9:03 PM, Chris Fowler
<cfowler at outpostsentinel.com>wrote:

> I've got my VPN working well and I want to test something unique.
>
> I'm creating a 10.0.7.0/24 subnet for the Windows VPN clients.
> The server has many devices on 10.0.5.0/24 and each of those
> devices are gateways to a remote network.
>
> In this scenario, I want to pretend that 10.0.7.0/24 can only be
> allowed access to device behind 10.0.5.100.  Not 10.0.5.114.  Here
> is what I tried:
>
> *Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     all  --  10.0.7.0/24          10.0.5.100
> REJECT     all  --  10.0.7.0/24          10.0.5.0/24         reject-with
> icmp-port-unreachable *
>
> I can not ping anything other than 10.0.5.100.
> I have a device with an address of 192.168.63.200 behind 10.0.5.198.
> I can ping that device from the server.  And if I manually add a
> route on the windows box, I can ping it from the windows box even
> though I can not ping the gateway for that address.
>
> What I'm trying to accomplish is the ability to lock down a client to
> use a specific gateway(s).  If that client decides to manually
> add a route because they know where other stuff is located,  I do
> not want the Linux kernel to route those packets to other gateways.
>
>
> Confusing?
>
> Maybe this will make it more confusing :)
>
> *
> [root at demo etc]# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 192.168.63.200  10.0.5.198      255.255.255.255 UGH   0      0        0
> ppp12
> 192.168.100.1   0.0.0.0         255.255.255.255 UH    0      0        0
> ppp0
> 10.0.5.203      0.0.0.0         255.255.255.255 UH    0      0        0
> ppp5
> 10.0.5.91       0.0.0.0         255.255.255.255 UH    0      0        0
> ppp11
> 10.0.5.89       0.0.0.0         255.255.255.255 UH    0      0        0
> ppp2
> 10.0.5.120      0.0.0.0         255.255.255.255 UH    0      0        0
> ppp13
> 10.0.5.210      0.0.0.0         255.255.255.255 UH    0      0        0
> ppp6
> 10.0.5.211      0.0.0.0         255.255.255.255 UH    0      0        0
> ppp8
> 10.0.5.208      0.0.0.0         255.255.255.255 UH    0      0        0
> ppp4
> 10.0.5.100      0.0.0.0         255.255.255.255 UH    0      0        0
> ppp1
> 10.0.5.99       0.0.0.0         255.255.255.255 UH    0      0        0
> ppp3
> 10.0.5.198      0.0.0.0         255.255.255.255 UH    0      0        0
> ppp12
> 10.0.5.214      0.0.0.0         255.255.255.255 UH    0      0        0
> ppp9
> 10.0.5.114      0.0.0.0         255.255.255.255 UH    0      0        0
> ppp10
> 10.0.5.215      0.0.0.0         255.255.255.255 UH    0      0        0
> ppp7
> 10.0.7.2        0.0.0.0         255.255.255.255 UH    0      0        0
> tun0
> 209.168.246.192 0.0.0.0         255.255.255.192 U     0      0        0
> eth0
> 192.168.100.0   192.168.100.1   255.255.255.0   UG    0      0        0
> ppp0
> 10.0.7.0        10.0.7.2        255.255.255.0   UG    0      0        0
> tun0
> 192.168.2.0     10.0.5.100      255.255.255.0   UG    0      0        0
> ppp1
> 172.16.112.0    0.0.0.0         255.255.255.0   U     0      0        0
> vmnet8
> 209.168.246.0   0.0.0.0         255.255.255.0   U     0      0        0
> eth0
> 169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0
> eth0
> 0.0.0.0         209.168.246.193 0.0.0.0         UG    0      0        0
> eth0*
>
> The ppp+ interfaces are all created via vtun.  The tun interfaces
> are owned by OpenVPN for the purpose of giving Windows access.
>
> 10.0.5.0/24 are embedded Linux devices that use vtun to get back
> to the demo server.  The are configured for NAT with eth0 as their
> "public" interface.  That is how I'm able to ping 192.168.63.200 without
> teling 192.168.63.200 where 10.0.7.6 is at.  The device is doing IP
> masquerading for me on the remote network.
>
> Thanks,
> Chris
>
>
> --
>
> Chris Fowler
> OutPost Sentinel, LLC
> Support @ SIP/support at pbx.opsdc.com
>  or 678-804-8193
> Email Support @ support at outpostsentinel.com
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
>



-- 
-- 
James P. Kinney III
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20081016/ca1424f9/attachment.html 


More information about the Ale mailing list