forked from extern/shorewall_code
minor cleanup
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@941 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
parent
8e9dc1fcc3
commit
108fc8d82c
@ -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>
|
||||
|
||||
|
@ -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>
|
||||
|
Loading…
Reference in New Issue
Block a user