Hi
I am using Shorewall with a bridged Firewall using the "bridging
utils" from
Debian.
eth0 is connected to the router and eth1 is connected to the local lan.
eth0 and eth1 are both assigned zero addresses and br0 is assigned the
Firewall server address of 192.168.0.1
I should point out that Shorewall is working fine in Bridge mode, but I have
hit some problems while evaluating VMWare Beta 5 on the same server that is
acting as an EtherBridge and also running Shorewall.
I am testing Win2k in the Guest environment within VMWare.
I have tried setting up VMWare in two modes :-
a) firstly using NAT between the Virtual server and the Real Host. This works
although there were a number of broadcasts showing up in the logs
b) secondly ( and currently ) creating a VMWare bridge between the Virtual
server and br0 on the actual host ( eth0 and eth1 don''t have any ip
addresses
assigned to them due to the Ether Bridge ). This also works apart from not
being able to connect to the Real Host ( bro 192.168.0.1 ) from the Virtual
server. I can access everything else either on the local net or via the
Internet. I cannot ping or create a virtual drive from the Virtual server to
the Real server 192.168.0.1 However, if I disable Shorewall via "shorewall
clear" then I can both ping and create a virtual drive from the virtual
server to the real server.
It seems that in "VMWare Brigdged mode" Shorewall is preventing the
Virtual
Server from connecting to the Real Server.
Required Info
------------------
shorewall version
2.2.1
ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0d:61:1a:e2:25 brd ff:ff:ff:ff:ff:ff
inet6 fe80::20d:61ff:fe1a:e225/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:04:5a:8c:67:6a brd ff:ff:ff:ff:ff:ff
inet6 fe80::204:5aff:fe8c:676a/64 scope link
valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:04:5a:8c:67:6a brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 brd 192.168.0.255 scope global br0
inet6 fe80::204:5aff:fe8c:676a/64 scope link
valid_lft forever preferred_lft forever
5: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
ip route show
192.168.0.0/24 dev br0 proto kernel scope link src 192.168.0.1
Also, the Virtual Win2k Server is currently assigned ip 192.168.0.20
I have attached the output from shorewall status
Regards
Stewart
--
Stewart Outram
uk
See below ----- Original Message ----- From: "stewart" <stewart@soutram.fsnet.co.uk> To: <shorewall-users@lists.shorewall.net> Sent: Friday, April 01, 2005 12:25 PM Subject: [Shorewall-users] Problems using VMWare with a Bridged Firewall> Hi > > I am using Shorewall with a bridged Firewall using the "bridging utils"from> Debian. > > eth0 is connected to the router and eth1 is connected to the local lan. > > eth0 and eth1 are both assigned zero addresses and br0 is assigned the > Firewall server address of 192.168.0.1 > > I should point out that Shorewall is working fine in Bridge mode, but Ihave> hit some problems while evaluating VMWare Beta 5 on the same server thatis> acting as an EtherBridge and also running Shorewall. > > I am testing Win2k in the Guest environment within VMWare. > > I have tried setting up VMWare in two modes :- > > a) firstly using NAT between the Virtual server and the Real Host. Thisworks> although there were a number of broadcasts showing up in the logs > > > b) secondly ( and currently ) creating a VMWare bridge between the Virtual > server and br0 on the actual host ( eth0 and eth1 don''t have any ipaddresses> assigned to them due to the Ether Bridge ). This also works apart from not > being able to connect to the Real Host ( bro 192.168.0.1 ) from theVirtual> server. I can access everything else either on the local net or via the > Internet. I cannot ping or create a virtual drive from the Virtual serverto> the Real server 192.168.0.1 However, if I disable Shorewall via "shorewall > clear" then I can both ping and create a virtual drive from the virtual > server to the real server. > > It seems that in "VMWare Brigdged mode" Shorewall is preventing theVirtual> Server from connecting to the Real Server. > > Required Info > ------------------ > > shorewall version > 2.2.1 > > ip addr show > 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:0d:61:1a:e2:25 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20d:61ff:fe1a:e225/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:04:5a:8c:67:6a brd ff:ff:ff:ff:ff:ff > inet6 fe80::204:5aff:fe8c:676a/64 scope link > valid_lft forever preferred_lft forever > 4: br0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue > link/ether 00:04:5a:8c:67:6a brd ff:ff:ff:ff:ff:ff > inet 192.168.0.1/24 brd 192.168.0.255 scope global br0 > inet6 fe80::204:5aff:fe8c:676a/64 scope link > valid_lft forever preferred_lft forever > 5: sit0: <NOARP> mtu 1480 qdisc noop > link/sit 0.0.0.0 brd 0.0.0.0 > > > ip route show > 192.168.0.0/24 dev br0 proto kernel scope link src 192.168.0.1 > > Also, the Virtual Win2k Server is currently assigned ip 192.168.0.20 > > I have attached the output from shorewall status > > > Regards > > > Stewart > -- > Stewart Outram > uk >---------------------------------------------------------------------------- ----> _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe:https://lists.shorewall.net/mailman/listinfo/shorewall-users> Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htmI would suspect the norfc1918 change you made below and the hits associated with it judging from your status...does it work if you remove norfc1918 from that interface? (besides I thought that was what nobogons was for on bridges?) It''s just a thought... 167 73004 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 ctorigdst 192.168.0.0/25 DISCLAIMER: This message was sent from The-Techy.com.
stewart wrote:> > a) firstly using NAT between the Virtual server and the Real Host. This works > although there were a number of broadcasts showing up in the logsGiven the above information, I certainly hope you don''t expect to diagnose the cause of "... number of broadcasts showing up in the logs".> b) secondly ( and currently ) creating a VMWare bridge between the Virtual > server and br0 on the actual host > > It seems that in "VMWare Brigdged mode" Shorewall is preventing the Virtual > Server from connecting to the Real Server.> > ip addr show > 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:0d:61:1a:e2:25 brd ff:ff:ff:ff:ff:ff > inet6 fe80::20d:61ff:fe1a:e225/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:04:5a:8c:67:6a brd ff:ff:ff:ff:ff:ff > inet6 fe80::204:5aff:fe8c:676a/64 scope link > valid_lft forever preferred_lft forever > 4: br0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue > link/ether 00:04:5a:8c:67:6a brd ff:ff:ff:ff:ff:ff > inet 192.168.0.1/24 brd 192.168.0.255 scope global br0 > inet6 fe80::204:5aff:fe8c:676a/64 scope link > valid_lft forever preferred_lft forever > 5: sit0: <NOARP> mtu 1480 qdisc noop > link/sit 0.0.0.0 brd 0.0.0.0 >Apr 1 17:13:31 INPUT:REJECT:IN=br0 OUT= SRC=192.168.0.20 DST=192.168.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=229 PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=256 This indicates that the bridge port created by VMWare is not defined to Shorewall. See FAQ 17 -- when packets are rejected in the INPUT chain, it means that the source host (192.168.0.20) is not in any defined zone. Curiously enough, the above event doesn''t include "physdev" information -- so I don''t know how VMWare is attaching to the bridge. Was the above "ip addr show" output produced while VMWare was running? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key