Hi,
I am trying to setup shorewall in our office network. I had already
used seawall in my old office, so configuring shorewall is of primary
interest for me.
Well I have configured the firewall using ProxyARP. The
shorewall system has two network interfaces eth0 and eth1. I have
configured two network zones namely as " net" and "dmz"
zones.
*Status:- All systems in the DMZ zone are able to connect to internet
The Voice over IP phones [also in dmz] do not communicate
*We have a custom NAT device in the DMZ which has two network interfaces
[ one to dmz and one to local intranet]. Intranet clients connect always
using this custom NAT device to internat as a default gateway.
_*Problems:-*_*
Clents are not able to connect to internet as before [ without the firewall]
VOIP phones are not communicating between locations
I am attaching the policy and the rules files.
Please mail me if there is a solution
Regards
Siva
_Policy
_**
*SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
dmz net ACCEPT info
fw net ACCEPT info
net all DROP info
all all REJECT info
*_rules
_
*ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
ACCEPT net dmz:203.124.152.67 tcp 80 -
ACCEPT net dmz:203.124.152.68 tcp 80 -
ACCEPT net dmz:203.124.152.67 tcp 443 -
ACCEPT net dmz:203.124.152.67 tcp 8001 -
ACCEPT net dmz:203.124.152.67 tcp 8002 -
ACCEPT net dmz:203.124.152.67 tcp 22 -
ACCEPT net dmz icmp echo-request
ACCEPT dmz fw icmp echo-request
ACCEPT net:216.200.134.135 dmz:203.124.152.69 related
ACCEPT net:216.200.134.135 dmz:203.124.152.73 related
*
*
> root@localhost root]# shorewall version
> 1.3.14
>
> [root@localhost root]# uname -a
> Linux localhost.localdomain 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002
> i686 i686 i386 GNU/Linux
> [root@localhost root]# 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 brd 127.255.255.255 scope host lo
> 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> link/ether 00:c0:4f:4d:fd:a4 brd ff:ff:ff:ff:ff:ff
> inet 203.124.152.74/28 brd 203.124.152.79 scope global eth0
> 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
> link/ether 00:0b:2b:01:87:d4 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.100/24 brd 192.168.1.255 scope global eth1
> [root@localhost root]# ip route show
> 203.124.152.72 dev eth1 scope link
> 203.124.152.73 dev eth1 scope link
> 203.124.152.68 dev eth1 scope link
> 203.124.152.69 dev eth1 scope link
> 203.124.152.70 dev eth1 scope link
> 203.124.152.71 dev eth1 scope link
> 203.124.152.66 dev eth1 scope link
> 203.124.152.67 dev eth1 scope link
> 203.124.152.64/28 dev eth0 scope link
> 192.168.1.0/24 dev eth1 scope link
> 127.0.0.0/8 dev lo scope link
> default via 203.124.152.65 dev eth0
> [root@localhost root]# lsmod
> Module Size Used by Not tainted
> soundcore 6532 0 (autoclean)
> autofs 13348 0 (autoclean) (unused)
> ipt_TOS 1656 12 (autoclean)
> ipt_LOG 4184 7 (autoclean)
> ipt_REJECT 3736 4 (autoclean)
> ipt_state 1048 21 (autoclean)
> iptable_mangle 2776 1 (autoclean)
> ip_nat_irc 3504 0 (unused)
> ip_nat_ftp 4240 0 (unused)
> iptable_nat 19960 2 [ip_nat_irc ip_nat_ftp]
> ip_conntrack_irc 3520 0 (unused)
> ip_conntrack_ftp 5088 0 (unused)
> ip_conntrack 21244 4 [ipt_state ip_nat_irc ip_nat_ftp
> iptable_nat ip_conntrack_irc ip_conntrack_ftp]
> 8139too 17704 1
> mii 2156 0 [8139too]
> 3c59x 30640 1
> iptable_filter 2412 1 (autoclean)
> ip_tables 14936 9 [ipt_TOS ipt_LOG ipt_REJECT
> ipt_state iptable_mangle iptable_nat iptable_filter]
> mousedev 5524 1
> keybdev 2976 0 (unused)
> hid 22244 0 (unused)
> input 5888 0 [mousedev keybdev hid]
> usb-uhci 26188 0 (unused)
> usbcore 77024 1 [hid usb-uhci]
> ext3 70368 4
> jbd 52212 4 [ext3]
> [root@localhost root]#
--On Saturday, February 22, 2003 09:55:13 PM +0530 sivamurugu <sivamurugu@indscape.com> wrote:> Hi, > > > I am trying to setup shorewall in our office network. I had already > used seawall in my old office, so configuring shorewall is of primary > interest for me. Well I have configured the firewall using > ProxyARP. The shorewall system has two network interfaces eth0 and eth1. > I have configured two network zones namely as " net" and "dmz" zones. > > *Status:- All systems in the DMZ zone are able to connect to internet > The Voice over IP phones [also in dmz] do not communicate > *We have a custom NAT device in the DMZ which has two > network interfaces [ one to dmz and one to local intranet]. Intranet > clients connect always using this custom NAT device to internat as a > default gateway. > > _*Problems:-*_* > > > Clents are not able to connect to internet as before [ without the > firewall] > > > VOIP phones are not communicating between locations > > I am attaching the policy and the rules files. > > Please mail me if there is a solution >First please email the output of "shorewall status" as described at http://www.shorewall.net/support.htm Also, what steps have you taken to try to diagnose this problem:? "not able to connect" and "are not communicating" are useless expressions. What is the purpose of the two ''related'' rules in /etc/shorewall/rules? Do you have ALLOWRELATED=No in shorewall.conf? If so, you should be aware that support for that will disappear in Shorewall 1.4.0. If you have ALLOWRELATED=Yes, then the rules are redundant. Finally, what are the IP addresses of the NAT device? -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
--On Saturday, February 22, 2003 08:42:20 AM -0800 Tom Eastep <teastep@shorewall.net> wrote:> > > First please email the output of "shorewall status" as described at > http://www.shorewall.net/support.htm >Also, please "shorewall reset" then try to connect one of the VOIP clients before you capture the "shorewall status" output. Thanks, -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Hi ,
I am back to testing tonight. I want to complete this at any cost.
Further to your reply , i have run the tcpdump on the firewall system
while pinging from the dmz system. As you told there is a problem. Now
what I need to do. I attach herewith the tcpdump output.
Please reply.
Regards
Siva
-------------- next part --------------
23:00:13.367010 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:13.401100 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:14.867321 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:14.901293 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:16.367685 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:16.401754 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:17.868216 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:17.902044 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:19.368442 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:19.407560 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:20.868734 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:20.907852 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:22.369156 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:22.403274 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:23.869484 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:23.903635 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:25.369840 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:25.414023 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:26.870164 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:26.904400 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:28.370170 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:28.404837 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:29.870517 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:29.905208 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:31.370853 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:31.405655 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:32.871712 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:32.905968 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:34.372024 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:34.406392 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:35.872986 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:35.906806 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:37.372711 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:37.407152 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:38.872942 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:38.907577 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:40.373481 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:40.407965 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:41.873679 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:41.908340 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:43.374073 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:43.418870 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:44.874406 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:44.909446 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:46.374762 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:46.409514 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:47.875086 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:47.909926 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:49.375458 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:49.410338 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:50.875800 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:50.910692 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:52.376120 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:52.411107 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:53.876520 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:53.911505 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:55.376856 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:55.411879 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:56.877168 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:56.912272 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:58.377594 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:58.412682 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:00:59.877964 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:00:59.913078 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:01.378344 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:01.413502 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:02.878620 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:02.913860 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:04.378996 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:04.414341 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:05.879322 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:05.939687 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:07.379648 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:07.415029 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:08.880172 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:08.915412 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:10.380421 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:10.415861 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:11.880757 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:11.916210 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:13.381086 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:13.416615 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:14.881422 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:14.917017 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:16.381802 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:16.442440 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:17.882099 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:17.927821 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:19.382486 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:19.418211 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:20.882830 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:20.918564 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:22.383237 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:22.418979 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:23.883520 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:23.919377 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:25.383893 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:25.419784 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:26.884283 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:26.925136 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:28.384635 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:28.420556 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:29.884932 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:29.920939 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:31.385282 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:31.421373 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:32.885675 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:32.921718 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:34.386014 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:34.422174 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:35.886365 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:35.947511 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:37.386694 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:37.422875 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:38.887050 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:38.923295 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:40.387427 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:40.458714 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:41.887740 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:41.924084 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
23:01:43.388166 0:c0:4f:4d:fd:a4 0:3:40:90:2:9c ip 74: 203.124.152.67 >
203.124.152.65: icmp: echo request
23:01:43.424467 0:3:40:90:2:9c 0:5:5d:4a:3b:7c ip 74: 203.124.152.65 >
203.124.152.67: icmp: echo reply
--On Wednesday, February 26, 2003 11:05:49 PM +0530 sivamurugu <sivamurugu@indscape.com> wrote:> Hi , > > I am back to testing tonight. I want to complete this at any cost. > Further to your reply , i have run the tcpdump on the firewall system > while pinging from the dmz system. As you told there is a problem. Now > what I need to do. I attach herewith the tcpdump output. >As explained at http://www.shorewall.net/ProxyARP.htm, you can: a) wait for your ISP''s router to refresh its ARP cache. This can take hours but it WILL eventually happen. b) call your ISP and ask them to purge the wrong entries or to refresh the cacche (they may or may not be willing or able to do that for you). c) You can try gratuitous ARP using the the ''arping'' utility. THOSE ARE YOUR CHOICES!!! -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
--On Thursday, February 27, 2003 12:47:21 AM +0530 sivamurugu <sivamurugu@indscape.com> wrote:> Thanks for the reply Tom. > > 1)Is it OK if the ISP just refreshes ARP cache or he has to purge?Whatever.> > > 2) Approximately how many hous it should take for this refreshing?12-24 would not be unusual.> > > 3)When I do the arping , the following is the output. Anyhting fishy? > > [root@localhost root]# arping -U -I eth0 203.124.152.67 > bind: Cannot assign requested address > [root@localhost root]#I don''t know -- I''ve never used the program. If you read that section of the Proxy ARP page, you will notice that someone else wrote it.> > > 4) Is the following policy file correct in terms of its order of > placement of entries? > >###############################################################################># SOURCE DEST POLICY LOG LEVEL LIMIT:BURST ># loc net ACCEPT > net all DROP info > all all REJECT info > dmz net ACCEPT info > fw net ACCEPT info ># LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVENo -- that''s wrong. The all->all entry should always be last.> > 5) I am attaching a new tcpdump file with new ping tests done from behind > the NAT device and from the NAT device itself. >I assume that you can tell when two MAC addresses are different -- do I really need to look at it? -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:>> >> >> 3)When I do the arping , the following is the output. Anyhting fishy? >> >> [root@localhost root]# arping -U -I eth0 203.124.152.67 >> bind: Cannot assign requested address >> [root@localhost root]# > > > I don''t know -- I''ve never used the program. If you read that section of > the Proxy ARP page, you will notice that someone else wrote it. >Looks like you can get around this by: a) shorewall clear b) ip addr add 203.124.152.67 dev eth0 c) arping -U -I eth0 203.124.152.67 d) ip addr del 203.124.152.67 dev eth0 e) shorewall start -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Siva, --On Thursday, February 27, 2003 03:04:39 AM +0530 Sivamurugu <sivamurugu@indscape.com> wrote:> Hi, > > > Finally solved the issue. It was just the matter of switching > off and on the Alvarion box at our premises. I really appreciate your > support........we won''t get such support even if we pay. > > > Meantime , I see only DROP packets in my log file , eventhough I have > enabled the following rules.a) You are having connection problems. b) At http://www.shorewall.net/support.htm, there is text in a large red italic font which describes the information that we need in order to analyze connection problems. c) Please supply that information. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
--On Wednesday, February 26, 2003 01:55:08 PM -0800 Tom Eastep <teastep@shorewall.net> wrote:>> >> >> Meantime , I see only DROP packets in my log file , eventhough I have >> enabled the following rules. > > a) You are having connection problems. > b) At http://www.shorewall.net/support.htm, there is text in a large red > italic font which describes the information that we need in order to > analyze connection problems. c) Please supply that information. >You may also find FAQ #17 Helpful - http://www.shorewall.net/FAQ.htm#faq17 -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Hi Tom,
I would send the required files soon, because our head
office guys in US have to start accessing the servers in our location
only then I will get the DROP logs. In the meantime I have doubts in my
policy file itself in addition to the rules files. I am attaching those
files herewith.
Questions
1) Our US office people are not able to access the servers in my dmz
zone. I have a rule which permits entire subnet from net[US} zone to
entire subnet in dmz[our location--shorewall]. right or wrong?
2) Our US office people are able to make a call to our location''s
IP-phone extensions.I have a rule which permits one IP from net zone[US]
to one IP in dmz zone[our IP phone] . That''s why?
Regards
Siva
-------------- next part --------------
#
# Shorewall version 1.3 - Rules File
#
# /etc/shorewall/rules
#
# Rules in this file govern connection establishment. Requests and
# responses are automatically allowed using connection tracking.
#
# In most places where an IP address or subnet is allowed, you
# can preceed the address/subnet with "!" (e.g., !192.168.1.0/24) to
# indicate that the rule matches all addresses except the address/subnet
# given. Notice that no white space is permitted between "!" and the
# address/subnet.
#
# Columns are:
#
#
# ACTION ACCEPT, DROP, REJECT, DNAT or REDIRECT
#
# ACCEPT -- allow the connection request
# DROP -- ignore the request
# REJECT -- disallow the request and return an
# icmp-unreachable or an RST packet.
# DNAT -- Forward the request to another
# system (and optionally another
# port).
# DNAT- -- Advanced users only.
# Like DNAT but only generates the
# DNAT iptables rule and not
# the companion ACCEPT rule.
# REDIRECT -- Redirect the request to a local
# port on the firewall.
#
# May optionally be followed by ":" and a syslog log
# level (e.g, REJECT:info). This causes the packet to be
# logged at the specified level.
#
# Beginning with Shorewall version 1.3.12, you may
# also specify ULOG (must be in upper case) as a log level.\
# This will log to the ULOG target and sent to a separate log
# through use of ulogd
# (http://www.gnumonks.org/projects/ulogd).
#
#
# SOURCE Source hosts to which the rule applies. May be a zone
# defined in /etc/shorewall/zones, $FW to indicate the
# firewall itself, or "all" If the ACTION is DNAT or
# REDIRECT, sub-zones of the specified zone may be
# excluded from the rule by following the zone name with
# "!'' and a comma-separated list of sub-zone names.
#
# Except when "all" is specified, clients may be further
# restricted to a list of subnets and/or hosts by
# appending ":" and a comma-separated list of subnets
# and/or hosts. Hosts may be specified by IP or MAC
# address; mac addresses must begin with "~" and must use
# "-" as a separator.
#
# dmz:192.168.2.2 Host 192.168.2.2 in the DMZ
#
# net:155.186.235.0/24 Subnet 155.186.235.0/24 on the
# Internet
#
# loc:192.168.1.1,192.168.1.2
# Hosts 192.168.1.1 and
# 192.168.1.2 in the local zone.
# loc:~00-A0-C9-15-39-78 Host in the local zone with
# MAC address 00:A0:C9:15:39:78.
#
# Alternatively, clients may be specified by interface
# by appending ":" to the zone name followed by the
# interface name. For example, loc:eth1 specifies a
# client that communicates with the firewall system
# through eth1. This may be optionally followed by
# another colon (":") and an IP/MAC/subnet address
# as described above (e.g., loc:eth1:192.168.1.5).
#
# DEST Location of Server. May be a zone defined in
# /etc/shorewall/zones, $FW to indicate the firewall
# itself or "all"
#
# Except when "all" is specified, the server may be
# further restricted to a particular subnet, host or
# interface by appending ":" and the subnet, host or
# interface. See above.
#
# Restrictions:
#
# 1. MAC addresses are not allowed.
# 2. In DNAT rules, only IP addresses are
# allowed; no FQDNs or subnet addresses
# are permitted.
#
# The port that the server is listening on may be
# included and separated from the server''s IP address by
# ":". If omitted, the firewall will not modifiy the
# destination port. A destination port may only be
# included if the ACTION is DNAT or REDIRECT.
#
# Example: loc:192.168.1.3:3128 specifies a local
# server at IP address 192.168.1.3 and listening on port
# 3128. The port number MUST be specified as an integer
# and not as a name from /etc/services.
#
# if the ACTION is REDIRECT, this column needs only to
# contain the port number on the firewall that the
# request should be redirected to.
#
# PROTO Protocol - Must be "tcp", "udp", "icmp",
a number,
# "all" or "related". If "related", the
remainder of the
# entry must be omitted and connection requests that are
# related to existing requests will be accepted.
#
# DEST PORT(S) Destination Ports. A comma-separated list of Port
# names (from /etc/services), port numbers or port
# ranges; if the protocol is "icmp", this column is
# interpreted as the destination icmp-type(s).
#
# A port range is expressed as <low port>:<high port>.
#
# This column is ignored if PROTOCOL = all but must be
# entered if any of the following ields are supplied.
# In that case, it is suggested that this field contain
# "-"
#
# If MULTIPORT=Yes in /etc/shorewall/shorewall.conf, then
# only a single Netfilter rule will be generated if in
# this list and the CLIENT PORT(S) list below:
# 1. There are 15 or less ports listed.
# 2. No port ranges are included.
# Otherwise, a separate rule will be generated for each
# port.
#
# CLIENT PORT(S) (Optional) Port(s) used by the client. If omitted,
# any source port is acceptable. Specified as a comma-
# separated list of port names, port numbers or port
# ranges.
#
# If you don''t want to restrict client ports but need to
# specify an ADDRESS in the next column, then place "-"
# in this column.
#
# If MULTIPORT=Yes in /etc/shorewall/shorewall.conf, then
# only a single Netfilter rule will be generated if in
# this list and the DEST PORT(S) list above:
# 1. There are 15 or less ports listed.
# 2. No port ranges are included.
# Otherwise, a separate rule will be generated for each
# port.
#
# ORIGINAL DEST (0ptional -- only allowed if ACTION is DNAT or
# REDIRECT) If included and different from the IP
# address given in the SERVER column, this is an address
# on some interface on the firewall and connections to
# that address will be forwarded to the IP and port
# specified in the DEST column.
#
# The address may optionally be followed by
# a colon (":") and a second IP address. This causes
# Shorewall to use the second IP address as the source
# address in forwarded packets. See the Shorewall
# documentation for restrictions concerning this feature.
# If no source IP address is given, the original source
# address is not altered.
#
# Example: Accept SMTP requests from the DMZ to the internet
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# ACCEPT dmz net tcp smtp
#
# Example: Forward all ssh and http connection requests from the internet
# to local system 192.168.1.3
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# DNAT net loc:192.168.1.3 tcp ssh,http
#
# Example: Redirect all locally-originating www connection requests to
# port 3128 on the firewall (Squid running on the firewall
# system) except when the destination address is 192.168.2.2
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# REDIRECT loc 3128 tcp www - !192.168.2.2
#
# Example: All http requests from the internet to address
# 130.252.100.69 are to be forwarded to 192.168.1.3
#
# #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# # PORT PORT(S) DEST
# DNAT net loc:192.168.1.3 tcp 80 - 130.252.100.69
##############################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
ACCEPT net:216.200.134.0/25 dmz:203.124.152.0/28 all - -
ACCEPT net:64.125.136.0/24 dmz:203.124.152.0/28 all - -
ACCEPT net:216.200.134.135 dmz:203.124.152.69 all - -
ACCEPT net:216.200.134.135 dmz:203.124.152.73 all - -
ACCEPT net dmz icmp echo-request
ACCEPT dmz fw icmp echo-request
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
-------------- next part --------------
#
# Shorewall 1.3 -- Policy File
#
# /etc/shorewall/policy
#
# This file determines what to do with a new connection request if we
# don''t get a match from the /etc/shorewall/rules file or from the
# /etc/shorewall/common[.def] file. For each source/destination pair, the
# file is processed in order until a match is found ("all" will match
# any client or server).
#
# Columns are:
#
# SOURCE Source zone. Must be the name of a zone defined
# in /etc/shorewall/zones, $FW or "all".
#
# DEST Destination zone. Must be the name of a zone defined
# in /etc/shorewall/zones, $FW or "all"
#
# WARNING: Firewall->Firewall policies are not allowed; if
# you have a policy where both SOURCE and DEST are $FW,
# Shorewall will not start!
#
# POLICY Policy if no match from the rules file is found. Must
# be "ACCEPT", "DROP", "REJECT" or
"CONTINUE"
#
# LOG LEVEL If supplied, each connection handled under the default
# POLICY is logged at that level. If not supplied, no
# log message is generated. See syslog.conf(5) for a
# description of log levels.
#
# Beginning with Shorewall version 1.3.12, you may
# also specify ULOG (must be in upper case). This will
# log to the ULOG target and sent to a separate log
# through use of ulogd
# (http://www.gnumonks.org/projects/ulogd).
#
# If you don''t want to log but need to specify the
# following column, place "_" here.
#
# LIMIT:BURST If passed, specifies the maximum TCP connection rate
# and the size of an acceptable burst. If not specified,
# TCP connections are not limited.
#
# As shipped, the default policies are:
#
# a) All connections from the local network to the internet are allowed
# b) All connections from the internet are ignored but logged at syslog
# level KERNEL.INFO.
# d) All other connection requests are rejected and logged at level
# KERNEL.INFO.
###############################################################################
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
#loc net ACCEPT
net all DROP info
all all REJECT info
dmz net ACCEPT info
fw net ACCEPT info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
--On Friday, February 28, 2003 10:08:11 PM +0530 sivamurugu <sivamurugu@indscape.com> wrote:> I would send the required files soon, because our head > office guys in US have to start accessing the servers in our location > only then I will get the DROP logs. In the meantime I have doubts in my > policy file itself in addition to the rules files. I am attaching those > files herewith.I TOLD YOU THAT YOUR POLICY FILE WAS WRONG -- WHY DIDN''T YOU FIX IT????? The all->all policy MUST BE LAST!!!!!!!!! -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Siva, --On Friday, February 28, 2003 10:08:11 PM +0530 sivamurugu <sivamurugu@indscape.com> wrote: Now that I''m calmed down....> > Questions > > 1) Our US office people are not able to access the servers in my dmz > zone. I have a rule which permits entire subnet from net[US} zone to > entire subnet in dmz[our location--shorewall]. right or wrong?Siva, looking at a rules file without looking at the rest of the configuration doesn''t tell me what is happening, right or wrong.> > 2) Our US office people are able to make a call to our location''s > IP-phone extensions.I have a rule which permits one IP from net zone[US] > to one IP in dmz zone[our IP phone] . That''s why? >I frankly don''t know -- YOU know what your network looks like and I don''t. I DO notice that the single IP (216.200.134.135) is NOT in 216.200.134.0/25! Is that network REALLY a /25 rather than a /24? 216.200.134.0/25 is 216.200.134.0 - 216.200.134.127. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
--On Friday, February 28, 2003 10:08:11 PM +0530 sivamurugu <sivamurugu@indscape.com> wrote:> Hi Tom, > > > I would send the required files soon, because our head > office guys in US have to start accessing the servers in our location > only then I will get the DROP logs. In the meantime I have doubts in my > policy file itself in addition to the rules files. I am attaching those > files herewith. > > Questions > > 1) Our US office people are not able to access the servers in my dmz > zone. I have a rule which permits entire subnet from net[US} zone to > entire subnet in dmz[our location--shorewall]. right or wrong? > > 2) Our US office people are able to make a call to our location''s > IP-phone extensions.I have a rule which permits one IP from net zone[US] > to one IP in dmz zone[our IP phone] . That''s why? >To conclude this thread, there were three overall problems: a) The usual "stale cache" problem associated with proxy ARP. b) Siva''s policy file was mis-ordered so that his "all all REJECT" policy came before two other ACCEPT policies. c) In his rules file, Siva had used an incorrect VLSM (/25 where he needed /24). Siva reports that all is working well now. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Dear all, I use Shorewall-1.3.12 Can I setup proxyARP on 2 interface with the same subnet? Thanks for answer! Van
--On Friday, March 14, 2003 01:43:25 PM +0700 Techcom-Technic <tg301@hcm.vnn.vn> wrote:> > I use Shorewall-1.3.12 > Can I setup proxyARP on 2 interface with the same subnet? >Yes -- see http://www.shorewall.net/myfiles.htm. Both the server and the workstation "wookie" are proxy arped and one is in the DMZ while the other is in the local zone. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net