<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: Final resort CIPE routing question
From: Manuela Guandalini <guandam,AT,gcs-mbh,DOT,de>
Date: Fri, 19 Jan 2001 11:46:13 +0100
In-reply-to: <003101c07a48$2d0bb5b0$be01a8c0@trollslayer>

Les Mikesell wrote: 6401a8c0,AT,mntp1,DOT,il,DOT,home,DOT,com">----- Original Message -----From: "Yannick MSR" To: ; "Les Mikesell" Sent: Thursday, January 18, 2001 8:45 AMSubject: Re: Final resort CIPE routing question Forwarding should all be controlled by the route table - but you need toconfigure ipchains to allow access both ways between the LAN andtunnel.Hello,I've been testing again and when the firewalls are down and all ispermitted, pinging works perfectly, from a client post of one network toclient post on another network ... so it's 100% ipchains fault.Can someone point me in the direction which rules I should add ? For exampledo I need to add rules to go from 192.168.3.1 to 192.168.0.0 and vice versaand that on each input/forward/output target and that for which interface ?cipcb0 and eth1 ? I'm too lazy to type all that stuff in myself. There is a nicefirewall-buildingtool at http://linux-firewall-tools.com/linux/firewall/index.html thatwill generate just about what you want for the non-CIPE interfaces(be sure to mention the UDP port for the CIPE packets on theexternal interface in what you want to allow).If you don't mind the tunnel being completely open you can pastein something like: ipchains -A input -i cipcb0 -j ACCEPT ipchains -A output -i cipcb0 -j ACCEPT ipchains -A forward -i cipcb0 -j ACCEPT I still believe the right solution is ?? ? ? ? ? ipchains -I forward -s the.other.internal.net/24 -d 0.0.0.0/0 -j MASQ where MASQ the name of the masquerading chain is. You logically need the same on the other net to. 6401a8c0,AT,mntp1,DOT,il,DOT,home,DOT,com"> Have a good try. Bye. Manu.
<< | Thread Index | >> ]    [ << | Date Index | >> ]