DR BorderManager

[Mark]

We are trying to set up a BorderManager server to replace an existing
one in the event of a failure. Since authentication (Client Trust) is
not needed, we set up a server in it's own tree. We installed NetWare
using the same IP addresses as the existing BorderManager (keeping it
off the network). Added all the secondary IP Addresses, 1-to-1 NATs and
routing information. Next we installed BorderManager 3.8 and selected
HTTP and IP Packet Filtering Services. Patched to SP5 and verified
filters. Deleted the filters (in NWAdmin), cleared filters (filtsrv
-cf), unloaded filtsrv, copied the filters.cfg from the existing
BorderManager to the DR one and loaded via filtsrv migrate filters.

We then bounced the server to ensure everything was OK, checked the
filters (via filtcfg) and all the IP settings (via inetcfg). Then
unplugged the Private and Public cables for the existing BorderManager
and plugged the DR BorderManager cables in. HTTP proxy worked fine, but
GWIA (and the MTA) could not connect with the outside. I was able to
telnet to another GWIA (on port 25) so it would appear that outbound was
OK. We dropped the filters and GWIA started working. Since we couldn't
keep the DR BorderManager online for too long, we had limited
troubleshooting time. And came up with nothing... So back the the
original BorderManager and everything still works.

What did we miss???

Thanks,
Mark

[Craig Johnson]

In article <wtR0m.371$_B1...@kovat.provo.novell.com>, Mark wrote:
> What did we miss???
>
Secondary ip addresses?

Personally I think you would be better off putting the server in the
same tree as the old one, in parallel, using different primary
addresses. Then get everything set up and tested. Next, put the old
server's proxy address on as a secondary (unloading it on the old
server) so the outbound traffic moves to the new server. All addresses
being referenced by internal or external hosts should be secondaries,
so they can be moved back and forth between servers. When you can do
that, you can simply install clustering, and you have instant failover
and fault tolerance. (I discuss the procedure in my BMgr 3.x book).

Anyway, sounds like you static nat'd to a secondary address that was
not bound on the server, which will result in no outbound or inbound
non-proxy traffic to the nat'd host.

Craig Johnson
Novell Support Connection SysOp
*** For a current patch list, tips, handy files and books on
BorderManager, go to http://www.craigjconsulting.com ***

[Homebrewer]

Secondary IP addresses and NAT setup is exactly the same as the original
BorderManager. We wanted to keep the server out of the tree so there
would be no licensing issues and there really was no good reason for
having it in the tree anyway. Additionally, the DR server would not be
powered on normally so we didn't want to create DS problems.

Clustering is not an option and all NATs were set up on the primary
public IP address. And I was able to telnet through the DR server to
another sites GWIA.

Thanks for the response, any other ideas?

Regards,
Mark

[Craig Johnson]

OK, I just reread the original thread, and it looks clearly like a
filtering issue. You mentioned that dropping the filters got GWIA
working. So... Something went wrong in the migration of filters from
old to new box. (Filter debug will help a lot in these cases).

For static NAT to an internal GWIA, smtp needs at least two stateful,
or four non-stateful, exceptions for port 25. I prefer the two pairs
of non-stateful myself.

For inbound SMTP from internet to GWIA:
-public to private, tcp dest. Port 25 to GWIA private IP address
-private to public, tcp source port 25 (with ack bit enabled) from GWIA
private IP address.

For outbound SMTP from GWIA to internet, the above, but everything
reversed. (Private to public, tcp dest. Port 25, source ip = GWIA
private address.)

What had me thinking about the secondaries was that you said proxy
worked, and telneting out on port 25 also worked. That told me that
dynamic nat worked, default route was OK, and at least some filter
exceptions were ok. Which suggested to me that static nat was failing
to work. A common cause of static nat failures is not having the
secondary public addresses actually bound. Always check with Display
Secondary Ipaddress to make sure they are there.

I've sometimes (rarely) seen arp tables that did not update on the
internet router side to pick up the new nic change for the addresses.