minor cleanup

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@941 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
mhnoyes 2003-12-24 21:27:51 +00:00
parent 8e9dc1fcc3
commit 108fc8d82c
2 changed files with 22 additions and 21 deletions

View File

@ -32,8 +32,8 @@
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled <quote><ulink
url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>

View File

@ -30,8 +30,8 @@
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled <quote><ulink
url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
@ -163,26 +163,27 @@
connections, from the outside, these would fail and I could not
understand why. Eventually, I changed the default route on the internal
system I was trying to access, to point to the new firewall and
<quote>bingo</quote>, everything worked as expected. This oversight delayed
my deployment by a couple of days not to mention level of frustration it
produced.</para>
<quote>bingo</quote>, everything worked as expected. This oversight
delayed my deployment by a couple of days not to mention level of
frustration it produced.</para>
<para>Another problem that I encountered was in setting up the Proxyarp
system in the DMZ. Initially I forgot to remove the entry for the eth2
from the /etc/shorewall/masq file. Once my file settings were correct, I
started verifying that the ARP caches on the firewall, as well as the
outside system <quote>kaos</quote>, were showing the correct Ethernet MAC
address. However, in testing remote access, I could access the system in
the DMZ only from the firewall and LAN but not from the Internet. The
message I received was <quote>connection denied</quote> on all protocols.
What I did not realize was that a <quote>helpful</quote> administrator that
had turned on an old system and assigned the same address as the one I
was using for Proxyarp without notifying me. How did I work this out. I
shutdown the system in the DMZ, rebooted the router and flushed the ARP
cache on the firewall and kaos. Then, from kaos, I started pinging that
IP address and checked the updated ARP cache and lo-and-behold a
different MAC address showed up. High levels of frustration etc., etc.
The administrator will not be doing that again! :-)</para>
outside system <quote>kaos</quote>, were showing the correct Ethernet
MAC address. However, in testing remote access, I could access the
system in the DMZ only from the firewall and LAN but not from the
Internet. The message I received was <quote>connection denied</quote> on
all protocols. What I did not realize was that a <quote>helpful</quote>
administrator that had turned on an old system and assigned the same
address as the one I was using for Proxyarp without notifying me. How
did I work this out. I shutdown the system in the DMZ, rebooted the
router and flushed the ARP cache on the firewall and kaos. Then, from
kaos, I started pinging that IP address and checked the updated ARP
cache and lo-and-behold a different MAC address showed up. High levels
of frustration etc., etc. The administrator will not be doing that
again! :-)</para>
</section>
<section>