[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