CentOS - Jun 2013 - IPv4 192.168.71.1 'leaks out onto WAN.

Arch = x86_64
OS = CentOS-6.4 (centos) with all updates applied to date.

On our gateway host eth0 is the WAN access and eth1 is the LAN. I wish
to activate the address 192.185.71.1 on eth1.  The ifcfg-eth1:192071
file contains this:

NAME=""
BOOTPROTO=none
MACADDR=""
IPV6INIT=no
DEVICE=eth1:192071
NETMASK=255.255.255.0
MTU=""
BROADCAST=192.168.71.255
ONPARENT=no
IPADDR=192.168.71.1
NETWORK=192.168.71.0
ONBOOT=no

When I try ifup to activate the address then I see this:

# ifup eth1:192071
Error, some other host already uses address 192.168.71.1.

I investigated what that host could be using nmap -v -APn
192.168.71.1/32 and discovered that my gateway host is allowing
192.168.71.0 out through eth0 onto the WAN (and presumably anything
else that it originates).

Presently we masquerade 192.168.0.0/16 in a NAT POSTROUTING chain
which handles the internal hosts seeking addresses on the WAN. 
However, I am unsure of how to handle the gateway itself.  Is this
situation best handled by a permanent route reflecting 192.168 to eth1
only?  Or, is it handled better by an addition to the OUTPUT chain in
the NAT IPTable?  Or, is the best method something else entirely of
which I am unaware?

Any suggestions?

-- 
***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

James B. Byrne wrote:
> Arch = x86_64
> OS = CentOS-6.4 (centos) with all updates applied to date.
>
> On our gateway host eth0 is the WAN access and eth1 is the LAN. I wish
> to activate the address 192.185.71.1 on eth1.  The ifcfg-eth1:192071
> file contains this:
>
> NAME=""
> BOOTPROTO=none
> MACADDR=""
> IPV6INIT=no
> DEVICE=eth1:192071
> NETMASK=255.255.255.0
> MTU=""
> BROADCAST=192.168.71.255
> ONPARENT=no
> IPADDR=192.168.71.1
> NETWORK=192.168.71.0
> ONBOOT=no
<snip>
I don't know if this would affect it, but for completeness' sake,
I'd
change several there, to have
BOOTPROTO=static
and put in the MAC address.

Have you checked with ifconfig to make sure that the correct NIC is
addressed as eth1? If this is CentOS 6, you need to also check
/etc/udev/rules.d/70-persistant-net.rules

       mark

On 8/06/13 5:03 AM, James B. Byrne wrote:

<snip>
> Presently we masquerade 192.168.0.0/16 in a NAT POSTROUTING chain
> which handles the internal hosts seeking addresses on the WAN. 
> However, I am unsure of how to handle the gateway itself.  Is this
> situation best handled by a permanent route reflecting 192.168 to eth1
> only?  Or, is it handled better by an addition to the OUTPUT chain in
> the NAT IPTable?  Or, is the best method something else entirely of
> which I am unaware?
If I recall correctly you would have to have the appropriate routes set
up, namely:

-Default to the WAN interface, which I assume is dynamic because you are
masquerading.
-static to the network/s on and behind eth1
-static to the network/s on and behind eth1:192071
-static routes back to the gateway from any routers behind the internal
networks.

then wouldn't the gateway just handle itself.  Masquerading is source
NAT to a dynamic interface therefore all packet mangling is done after
the routing.  Hence, a packet that originates from within the gateway
heading out would bypass the routing chain would use the static routes
to try to exit via the WAN interface and then get caught via the
POSTROUTING rule and be handled by that chain.  Then if it exited
through the WAN interface:

-the world sees it as originating from that interface
-there is a NAT translation left in place so packets coming back would
be mangled back to the correct source.

Alternatively, if the packet originates from the gateway to head
internally it would, again, bypass the routing chain and use the static
routes to decide which interface to exit on.  There would be no NAT
translation left in place because the rules would only apply for
incoming packets looking to exit via the WAN and only remain in place
for the translations they have set up.  Also there would be no need for
NAT as all the internal addresses are routeable as far as a packet that
originates from the gateway is concerned.

An +1 for adding MAC addresses.  I've come across a couple of switches
that prefer multiple MAC addresses for cloned, aliased and tagged
interfaces.  Test and see what you need.

Cheers
-pete

-- 
Peter Brady
Email: pdbrady at ans.com.au
Skype: pbrady77

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 946 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20130608/2bf01894/attachment.sig>