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?
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
-
James B. Byrne -
m.roth＠5-cent.us -
Peter Brady