Dear Tom, Thanks for your reply. Re.Proxy, I was just testing and seems I sent you the one with proxy enabled log, sorry for that. However, I don''t need proxy, as far as I understand, except that I was just testing when I sent you this output. I fixed the permission problem, but then I have another problem, resulting from fixing it, complaining about run-iptables command not found ! The new output is here, followed by the commands you requested: [root@a310 shorewall]# shorewall restart Loading /usr/share/shorewall/functions... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... Restarting Shorewall... Loading Modules... Initializing... Shorewall has detected the following iptables/netfilter capabilities: NAT: Available Packet Mangling: Available Multi-port Match: Available Connection Tracking Match: Available Determining Zones... Zones: net wst dmz svr Validating interfaces file... Validating hosts file... Validating Policy file... Determining Hosts in Zones... Net Zone: eth0:0.0.0.0/0 Local-Wst Zone: eth2:0.0.0.0/0 DMZ Zone: eth1:0.0.0.0/0 Local-Srv Zone: eth3:0.0.0.0/0 Processing /etc/shorewall/init ... Deleting user chains... Creating Interface Chains... Configuring Proxy ARP Setting up NAT... Adding Common Rules /etc/shorewall/common.def: line 15: run_iptables: command not found /etc/shorewall/common.def: line 19: run_iptables: command not found /etc/shorewall/common.def: line 20: run_iptables: command not found /etc/shorewall/common.def: line 21: run_iptables: command not found /etc/shorewall/common.def: line 22: run_iptables: command not found /etc/shorewall/common.def: line 23: run_iptables: command not found /etc/shorewall/common.def: line 24: run_iptables: command not found /etc/shorewall/common.def: line 28: run_iptables: command not found /etc/shorewall/common.def: line 32: run_iptables: command not found /etc/shorewall/common.def: line 33: run_iptables: command not found /etc/shorewall/common.def: line 37: run_iptables: command not found /etc/shorewall/common.def: line 40: run_iptables: command not found Adding rules for DHCP Enabling RFC1918 Filtering Setting up TCP Flags checking... Setting up Blacklisting... Blacklisting enabled on eth0 Setting up Kernel Route Filtering... IP Forwarding Enabled Processing /etc/shorewall/tunnels... Processing /etc/shorewall/rules... Warning -- Rule "ACCEPT wst svr" is a POLICY -- and should be moved to the policy file Rule "ACCEPT wst svr" added. Rule "ACCEPT wst fw tcp" added. Warning -- Rule "ACCEPT wst fw all" is a POLICY -- and should be moved to the policy file Rule "ACCEPT wst fw all" added. Rule "ACCEPT wst dmz tcp" added. Rule "ACCEPT wst dmz icmp echo-request" added. Rule "ACCEPT fw net udp 68,67,53" added. Rule "ACCEPT fw wst udp 68,67,53" added. Rule "ACCEPT fw dmz udp 68,67,53" added. Rule "ACCEPT fw svr udp 68,67,53" added. Rule "ACCEPT wst fw udp 68,67" added. Rule "ACCEPT svr fw udp 68,67" added. Rule "ACCEPT svr svr icmp 8" added. Rule "ACCEPT svr dmz tcp 21,23,25,110" added. Rule "ACCEPT svr dmz icmp 8" added. Rule "ACCEPT svr net icmp echo-request" added. Rule "ACCEPT svr fw icmp 8" added. Rule "ACCEPT wst fw icmp 8" added. Rule "ACCEPT dmz net udp domain" added. Rule "ACCEPT dmz net udp ntp" added. Rule "ACCEPT dmz net tcp smtp" added. Rule "ACCEPT dmz net tcp ftp" added. Rule "ACCEPT dmz net tcp ftp" added. Rule "ACCEPT dmz svr tcp 53" added. Rule "DNAT net dmz:192.168.2.3 tcp smtp" added. Processing /etc/shorewall/policy... Policy REJECT for fw to net using chain all2all Policy REJECT for fw to wst using chain all2all Policy REJECT for fw to dmz using chain all2all Policy ACCEPT for fw to svr using chain fw2svr Policy ACCEPT for net to dmz using chain net2dmz Policy ACCEPT for wst to fw using chain wst2fw Policy ACCEPT for wst to net using chain wst2net Policy REJECT for wst to dmz using chain all2all Policy ACCEPT for wst to svr using chain wst2svr Policy REJECT for dmz to net using chain all2all Policy REJECT for dmz to svr using chain all2all Policy ACCEPT for svr to fw using chain svr2fw Policy ACCEPT for svr to net using chain svr2net Policy ACCEPT for svr to wst using chain svr2wst Policy ACCEPT for svr to dmz using chain svr2dmz Policy ACCEPT for svr to svr using chain svr2svr Masqueraded Subnets and Hosts: To 0.0.0.0/0 from 192.168.168.0/24 through eth0 using 81.10.4.178 To 0.0.0.0/0 from 192.168.11.0/24 through eth0 using 81.10.4.178 To 0.0.0.0/0 from 192.168.2.0/24 through eth0 using 81.10.4.178 Processing /etc/shorewall/tos... Rule "all all tcp - ssh 16" added. Rule "all all tcp ssh - 16" added. Rule "all all tcp - ftp 16" added. Rule "all all tcp ftp - 16" added. Rule "all all tcp ftp-data - 8" added. Rule "all all tcp - ftp-data 8" added. Processing /etc/shorewall/ecn... Activating Rules... Adding IP Addresses... Processing /etc/shorewall/start ... Shorewall Restarted [root@a310 shorewall]# [root@a310 shorewall]# arp -na ? (192.168.2.3) at 00:48:54:53:8B:43 [ether] on eth1 ? (192.168.168.22) at 00:50:BA:D9:34:44 [ether] on eth3 ? (192.168.168.89) at 00:90:27:A4:1A:85 [ether] on eth3 ? (192.168.11.223) at 00:10:A4:F9:6A:E0 [ether] on eth2 ? (81.10.4.177) at 00:00:0C:3B:48:78 [ether] on eth0 ? (192.168.168.220) at 00:00:39:3D:1F:2C [ether] on eth3 ? (192.168.168.72) at 00:48:54:53:6E:DE [ether] on eth3 [root@a310 shorewall]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 81.10.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.168.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth3 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 81.10.4.177 0.0.0.0 UG 0 0 0 eth0 [root@a310 shorewall]# for f in /proc/sys/net/ipv4/conf/*/proxy_arp; do echo $f ; cat $f; done /proc/sys/net/ipv4/conf/all/proxy_arp 0 /proc/sys/net/ipv4/conf/default/proxy_arp 0 /proc/sys/net/ipv4/conf/eth0/proxy_arp 0 /proc/sys/net/ipv4/conf/eth1/proxy_arp 0 /proc/sys/net/ipv4/conf/eth2/proxy_arp 0 /proc/sys/net/ipv4/conf/eth3/proxy_arp 0 /proc/sys/net/ipv4/conf/lo/proxy_arp 0 Tom Eastep <teastep@shorewall.net> writes:> On Tue, 2003-08-12 at 14:45, deya@ozemail.com.au wrote: > > Dear All, > > > > After installing Shorewall, on a router with 4 NIC, seems running ok. > > Next day, when connecting from clients, (MS) we keep getting ip conflict fornon-conflicting ip addresses.> > > > > > Any help is appreciated. > > > > > > > Loading /usr/share/shorewall/functions... > > Processing /etc/shorewall/params ... > > Processing /etc/shorewall/shorewall.conf... > > Restarting Shorewall... > > Loading Modules... > > Initializing... > > Shorewall has detected the following iptables/netfilter capabilities: > > NAT: Available > > Packet Mangling: Available > > Multi-port Match: Available > > Connection Tracking Match: Available > > Determining Zones... > > Zones: net wst dmz svr > > Validating interfaces file... > > Validating hosts file... > > Validating Policy file... > > Determining Hosts in Zones... > > Net Zone: eth0:0.0.0.0/0 > > Local-Wst Zone: eth2:0.0.0.0/0 > > DMZ Zone: eth1:0.0.0.0/0 > > Local-Srv Zone: eth3:0.0.0.0/0 > > Processing /etc/shorewall/init ... > > Deleting user chains... > > Creating Interface Chains... > > Configuring Proxy ARP > > Host 81.10.4.178 connected to eth0 added to ARP on eth0 > > Host 81.10.4.178 connected to eth0 added to ARP on eth3 > > Host 192.168.2.3 connected to eth1 added to ARP on eth3 > > Setting up NAT... > > Adding Common Rules > > /usr/share/shorewall/firewall: line 1: /etc/shorewall/common.def: Permissiondenied> > The above is a problem -- You need to correct the permissions for that > file. > > > Masqueraded Subnets and Hosts: > > To 0.0.0.0/0 from 192.168.168.0/24 through eth0 using 81.10.4.178 > > To 0.0.0.0/0 from 192.168.2.0/24 through eth0 using 81.10.4.178 > > Can you explain to me your Proxy ARP strategy? You are adding an ARP > entry on an interface that apparently already has that IP address. And > why are you adding 81.10.4.178 on eth3? Ditto 192.168.2.3? > > I''m asking because IP address conflict is detected by doing an ARP > who-has" of your own address and seeing if anyone answers. > > Also, do you have more than one of your firewall interfaces connected to > the same HUB/SWITCH as eth3? > > Please forward the output from the following commands: > > a) arp -na > b) route -n > c) for f in /proc/sys/net/ipv4/conf/*/proxy_arp; do echo $f; cat $f; > done > > -Tom > -- > Tom Eastep \ Shorewall - iptables made easy > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.netThis message was sent through MyMail http://www.mymail.com.au
On Wed, 2003-08-13 at 05:05, deya@ozemail.com.au wrote:> Dear Tom, > > Thanks for your reply. > > Re.Proxy, I was just testing and seems I sent you the one with proxy enabled > log, sorry for that.Well, I think it was causing your "duplicate address" problems, especially if your test setup has more than one interface connected to the same HUB/Switch (does it?).> > I fixed the permission problem, but then I have another problem, resulting > from fixing it, complaining about run-iptables command not found ! >Obviously, you have been messing with this file since it was installed (wrong permissions and now this problem). If you have been editing it on a Windows machine (as the comments at the beginning of the file suggest, you should never modify that file) then run it through ''dos2unix'' (e.g., dos2unix /etc/shorewall/common.def). If you don''t have dos2unix, you can use emacs. The emacs command is: c-X RET f unix RET -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
I don''t need the broadcast just for windows. I need it for games because they rely on broadcast packets to advertise the server''s presence. To my knowledge nothing is getting through the vpn. _________________________________________________________________ Fast, faster, fastest: Upgrade to Cable or DSL today! https://broadband.msn.com
I just thought of one more thing.. The tap0 interfaces have addresses of 0.0.0.0 on promisc mode. Would shorewall know how to work with this? _________________________________________________________________ Get a FREE computer virus scan online from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Dave: You should not see the tap0 interface, it should be part of br0 Can you post a little more info.. like ip link ls, ip route ls, the commands for the tunnel, some config files Jerry ----- Original Message ----- From: "Dave B" <dragin33@hotmail.com> To: <shorewall-users@lists.shorewall.net> Sent: Sunday, September 07, 2003 03:12 PM Subject: [Shorewall-users] RE: (no subject)> I just thought of one more thing.. The tap0 interfaces have addresses of > 0.0.0.0 on promisc mode. Would shorewall know how to work with this? > > _________________________________________________________________ > Get a FREE computer virus scan online from McAfee. > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe:http://lists.shorewall.net/mailman/listinfo/shorewall-users> Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm
Dave: 2 separate issues.. First we have to establish that the bridge is bound to the internal interface and tap device. ifconfig should show just br0 with no eth1 or whatever is the internal interface and tap0... This bridge device is then represented in Shorewall by the interface name br0 which is your loc zone. Jason: Just checking.. You used tap0 to bind to the internial nic in the bridge ?? I''d be interested in your vpn/bridge setup... Second, shorewall will block broadcasts by default: from: # Shorewall 1.4 -- /etc/shorewall/common.def # # This file defines the rules that are applied before a policy of # DROP or REJECT is applied. In addition to the rules defined in this file, # the firewall will also define a DROP rule for each subnet broadcast # address defined in /etc/shorewall/interfaces (including "detect"). Do a "shorewall show common" you should see a rule like this : Chain common (4 references) pkts bytes target prot opt in out source destination <snip> 0 0 DROP all -- * * 0.0.0.0/0 10.2.0.255 So trick is to undo that for the br0 interface''s broadcast... This *should* work in a shorewall common file.. I used -I here to place the rule ahead for the stock drop rule change 10.2.0.255 to your broadcast address: run_iptables -I common -d 10.2.0.255 -j ACCEPT . /etc/shorewall/common.def Hope this helps.. No need to override anything here so this is untested.. This should solve the heartbeat issue that was reported also... Tom, is this the correct way to override the broadcast behavior?? Jerry Vonau ----- Original Message ----- From: "Dave B" <dragin33@hotmail.com> To: <shorewall-users@lists.shorewall.net> Sent: Sunday, September 07, 2003 02:57 PM Subject: [Shorewall-users] RE: (no subject)> I don''t need the broadcast just for windows. I need it for games because > they rely on broadcast packets to advertise the server''s presence. > > To my knowledge nothing is getting through the vpn. > > _________________________________________________________________ > Fast, faster, fastest: Upgrade to Cable or DSL today! > https://broadband.msn.com > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe:http://lists.shorewall.net/mailman/listinfo/shorewall-users> Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm
Hi Jerry, On Sun, 7 Sep 2003, Jerry Vonau wrote:>Jason: >Just checking.. You used tap0 to bind to the internial nic in the bridge ?? >I''d be interested in your vpn/bridge setup...Well, we''re getting fairly off topic here for the Shorewall users mailing list, but seeing as how we don''t have a useful Subject: and Tom is on vacation I''ll give it a shot. =) I''ve setup ethernet bridging with my LAN ethernet card and 10 ''tap'' interfaces (I try to think ahead <g>) on a Linux router running Debian''s "testing" distro (mostly "testing" anyway). I do the actual bridging via a Debian-specific syntax in the /etc/network/interfaces file, like this: ---- iface br0 inet static pre-up openvpn --mktun --dev tap0 || true pre-up openvpn --mktun --dev tap1 || true pre-up openvpn --mktun --dev tap2 || true pre-up openvpn --mktun --dev tap3 || true pre-up openvpn --mktun --dev tap4 || true pre-up openvpn --mktun --dev tap5 || true pre-up openvpn --mktun --dev tap6 || true pre-up openvpn --mktun --dev tap7 || true pre-up openvpn --mktun --dev tap8 || true pre-up openvpn --mktun --dev tap9 || true address 192.168.0.1 netmask 255.255.255.0 bridge_ports eth1 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 bridge_maxwait 3 ---- I did get some weird error messages about tap0 (it couldn''t be opened or something) a while back and I never bothered to track them down because it worked fine with tap1. Here''s the Linux OpenVPN config for a Windows machine on the other end of an ethernet bridged tunnel (minus the comments, to keep it small): ---- local 216.169.167.142 port 5004 dev tap1 tun-mtu 1500 tun-mtu-extra 64 secret secret.key persist-key persist-tun ping-timer-rem ping-restart 60 ping 10 user nobody group nogroup verb 5 ---- Here''s the OpenVPN config on the Windows machine: ---- remote 216.169.167.142 port 5004 dev tap dev-node my-tap secret secret.key up up.bat down down.bat ping 15 verb 5 ---- I hope this helps. -Jason
As you requested i have gathered some more information. Because i got a LOT of info i decided it would be a bad idea to post to the list. I''ve uploaded it to some web space in the form of txt files. So here ya go. Side A''s Configuration http://dragin33.hypermart.net/vpn/SideA/ Side B''s Configuration http://dragin33.hypermart.net/vpn/SideB/ _________________________________________________________________ Try MSN Messenger 6.0 with integrated webcam functionality! http://www.msnmessenger-download.com/tracking/reach_webcam
Not Working.. http://dragin33.hypermart.net/vpn/SideA/ Forbidden You don''t have permission to access /vpn/SideA/ on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. Jerry Vonau ----- Original Message ----- From: "Dave B" <dragin33@hotmail.com> To: <shorewall-users@lists.shorewall.net> Sent: Sunday, September 07, 2003 10:15 PM Subject: [Shorewall-users] RE: (no subject)> As you requested i have gathered some more information. Because i got aLOT> of info i decided it would be a bad idea to post to the list. I''veuploaded> it to some web space in the form of txt files. So here ya go. > Side A''s Configuration > http://dragin33.hypermart.net/vpn/SideA/ > Side B''s Configuration > http://dragin33.hypermart.net/vpn/SideB/ > > _________________________________________________________________ > Try MSN Messenger 6.0 with integrated webcam functionality! > http://www.msnmessenger-download.com/tracking/reach_webcam > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe:http://lists.shorewall.net/mailman/listinfo/shorewall-users> Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm
Sorry, my host seems to have blocked directory access. Use this website: Side A: http://www.clubpeb.org/vpn/SideA/ Side B: http://www.clubpeb.org/vpn/SideB/>As you requested i have gathered some more information. Because i got a >LOT of info i decided it would be a bad idea to post to the list. I''ve >uploaded it to some web space in the form of txt files. So here ya go. >Side A''s Configuration >http://dragin33.hypermart.net/vpn/SideA/ >Side B''s Configuration >http://dragin33.hypermart.net/vpn/SideB/_________________________________________________________________ Get 10MB of e-mail storage! Sign up for Hotmail Extra Storage. http://join.msn.com/?PAGE=features/es
Hi Dave, On Mon, 8 Sep 2003, Dave B wrote:>Sorry, my host seems to have blocked directory access. Use this website: >Side A: >http://www.clubpeb.org/vpn/SideA/ >Side B: >http://www.clubpeb.org/vpn/SideB/- both sides - in /etc/shorewall/interfaces I think the broadcast address should be 192.168.255.255 since you''re using a /16 network. - side B - Shorewall is blocking DHCP traffic to eth0 (see "shorewall status" output)...I''m guessing that you need the "dhcp" option on that interfaces in /etc/shorewall/interfaces...? - side A - according to the OpenVPN log it had trouble opening the ''tap0'' interface. That''s the error message I saw before, and fixed by using ''tap1'' instead. I just tried Googling and I didn''t find anything great. If I were you I would try using ''tap1'' and/or posting that error to the OpenVPN users mailing list and see if they can help you. Maybe there is a stale openvpn process hanging on to the devie? According to ''ifconfig'' on both sides, a significant amount of traffic has gone over the tap interfaces. Are you sure that nothing is getting through? Try to use the great packet sniffing tool "ethereal" on one or both sides (as root) and listen on the tap interfaces and then try to get traffic across the VPN tunnel (when it''s up) using ping, telnet, lynx commands, etc. See anything? -Jason
Thanks Jason, that did the trick everything is working fine now. Thanks much.>- both sides > - in /etc/shorewall/interfaces I think the broadcast address should be > 192.168.255.255 since you''re using a /16 network. > >- side B > - Shorewall is blocking DHCP traffic to eth0 (see "shorewall status" > output)...I''m guessing that you need the "dhcp" option on that > interfaces in /etc/shorewall/interfaces...? > >- side A > - according to the OpenVPN log it had trouble opening the ''tap0'' > interface. That''s the error message I saw before, and fixed by using > ''tap1'' instead. I just tried Googling and I didn''t find anything > great. If I were you I would try using ''tap1'' and/or posting that > error to the OpenVPN users mailing list and see if they can help you. > Maybe there is a stale openvpn process hanging on to the devie? > >According to ''ifconfig'' on both sides, a significant amount of traffic has >gone over the tap interfaces. Are you sure that nothing is getting >through? Try to use the great packet sniffing tool "ethereal" on one or >both sides (as root) and listen on the tap interfaces and then try to get >traffic across the VPN tunnel (when it''s up) using ping, telnet, lynx >commands, etc. See anything?_________________________________________________________________ Express yourself with MSN Messenger 6.0 -- download now! http://www.msnmessenger-download.com/tracking/reach_general