Topic: modify ipchains to allow internal access for VPN nets - with

[Patrick Basile]

Hello everyone,

Would someone please tell me how I can modify ipchains to allow internal access for VPN nets - without messing up security?  I am not asking about port forwarding.  A step by step guide would be nice, as I would like to make sure that all the 'normal' security stays in place on the external nic of my SME box.

Here's the scenario:

  ... T1 connection  ----->  Cisco 1720 router  ---------->  SME 5.1

I have 2 remote networks (172.24.89.x and 172.24.90.x) which are connected via Cisco "hardware" VPN (not client connections) to the Cisco 1720 router here in the main office.  SME is setup in "server and gateway" mode for added security, so the VPN traffic from these remote networks is being firewalled as though it were Internet traffic.

SME server:
external nic   192.168.0.50
internal nic   192.168.0.23

So what I need are the steps to allow all the traffic from these VPN'd networks into my local lan.  Ideas/thoughts/solutions??  Thanks.

Regards,
Patrick

[Dan G.]

I don't know if this is right, as I haven't tested it --- but it's derived from some other customizations I made, and they worked.  Anyone willing to claim greater authority on the topic is almost certainly entitled to

From what I gather, this is the basic rundown:

1.  Create a new templates-custom directory for the 'masq' templates, like so:
mkdir -p /etc/e-smith/templates-custom/etc/rc.d/init.d

2.  Copy the master templates to the new directory:
cp -rp /etc/e-smith/templates/etc/rc.d/init.d/masq /etc/e-smith/templates-custom/etc/rc.d/init.d/

3.  Create a new fragment that will stuff the new rules in early in your input chain.

touch /etc/e-smith/templates-custom/etc/rc.d/init.d/44AllowCustom

4.  Edit the 44AllowCustom file with your favorite editor, adding this line (ipchains gurus, chime in if I hosed this):

/sbin/ipchains --append input -p ALL -s 172.24.90.0/24 -d 192.168.0.0/24 -j ACCEPT

I read that in English as: "create a rule whereby any protocol originating from any host on network 172.24.90.0/24 and bound for any host on 192.168.0.0/24 is allowed"

5.  Expand the template fragment into the config files:

/sbin/e-smith/expand-template /etc/rc.d/init.d/masq


6.  Apply the change to the running config

/sbin/e-smith/signal-event remoteaccess-update

7.  Test a client-to-client connection or ping.  Avoid testing by trying to ping gateway machines themselves, as the VPN arrangement may block ICMP.  Try a subnet-to-subnet transaction, and see what you get.

8.  If you have concerns about the security of the new system, throw together a generic Red Hat box, and nmap the snot out of your SME box from outside.  I doubt you'll have any problem, given the multiple layers of security you have in place.

9.  Given that you are using interfaces in the same subnet on both sides of the SME box, you may end up needing host routes for each of the hosts "behind" the SME box -- in that case you would end up scripting something like:

route add -host 192.168.0.1 dev eth0
route add -host 192.168.0.2 dev eth0
route add -host 192.168.0.3 dev eth0
....

Going on like that explicitly defining each of them, since your SME box now knows of addresses in the 192.168.0.0/24 range on both interfaces. I ran into this situation with a proxy-arp config using non-RFC1918 addresses in the same subnet on both sides of the firewall.  

Good luck

Dan

[Dan G.]

Doh.  Late night, too little coffee

Item #3 should be:

touch /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/44AllowCustom

Let me know how it works out.

Dan