| |
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [FW1] Nokia VRRP NAT problems
The target in the NAT rules was "All", which I think should be correct...
> i'm not sure i understand the second problem - if you ping an inside
server
> by using its Static NAT address from outside the cluster, the reply
comes
> back using the non-natted ip of the server??
That's correct, the response packets leave the cluster with the private
address as source address.
It seems like the cluster doesn't take into account the NAT-rule to
translate the packet leaving the cluster.
One more thing :
When I ping from the outside to the inside, I only see 1 log-entry for the
incoming request. I don't get a log entry for the reply-packet, even though
the reply-packet does leave the cluster.
All rules are long logging, even the implied rules ...
Anyway, the suggestions seems worth trying ... I didn't have any ideas
left... Thanks ...
Philippe Verdonck
"Ilya
Akinfiev" To: <[email protected]>
<akinfiev@pac cc:
bell.net> Subject: RE: [FW1] Nokia VRRP NAT problems
31/01/01
19:56
Please
respond to
ilya
some ideas:
insert static routes on the mgmt that point to the external IP's of both
cluster nodes via the respective internal IP's
if oyu use automatic Static NAT for the mgmt, check the "install on" target
try NAT rules:
src=mgmt dst=fw's | src=orig dst=orig
i'm not sure i understand the second problem - if you ping an inside server
by using its Static NAT address from outside the cluster, the reply comes
back using the non-natted ip of the server??
cheers
----- Ilya Akinfiev ; Security Consultant ------
--- SiegeWorks Enterprise Security Solutions ----
---- siegeworks.com ;x 201 ------
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of
[email protected]
Sent: Wednesday, January 31, 2001 3:41 AM
To: [email protected]
Subject: [FW1] Nokia VRRP NAT problems
I have the following problem with a Nokia IP440 VRRP setup ...
This is the setup :
SiteA-----| FWA|-----|xDsl-modem|---------- internet
------------|Cisco-router|------|Gateway-clusterB|-----|MgmtB|----SiteB
FWA = single gateway, v4.1SP2 on NT4
Gateway-clusterB = 2 Nokia's IP440 (FWB1 and FWB2) with VRRP monitored
circuits and load-balancing, v4.1SP2 on IPSO 3.2.1
MgmtB = Management server for Gateway-clusterB, v4.1SP3 on Win2K
SiteA = 172.26.x.y, hidden behind valid IP of xDsl-modem (IP a.b.c.d)
SiteB = 172.25.x.y, with static NAT from valid IP's e.f.g.x to servers on
SiteB
SiteB is hosted at a provider, so there are no employees on SiteB and a
gui-client on SiteA is used to push the rules from MgmtB to
Gateway-clusterB
On every subnet around Gateway-clusterB there are 2 virtual routers defined
(for load balancing), each gateway is master of 1 virtual router.
MgmtB uses as default gateway the virtual router of which FWB1 is the
master, and its IP 172.25.m.n is statically NAT-ed to valid IP e.f.g.n
VRRP-failover has been tested and seems to work correctly.
First problem
-------------------
I have to use the internal addresses in network objects FWB1 and FWB2.
When I try to use the external addresses, the management server MgmtB can't
download it's rules to FWB2.
When I ping from MgmtB to the valid address of FWB1 I get this :
Source Destination XlatedSrc XlatedDst
Service
172.25.m.n FWB1_valid MgmtB_valid FWB1_valid
ping-request
FWB1_valid 172.25.m.n
ping-reply
>> For some reason FWB1 sends its reply directly to the internal address of
MgmtB
When I ping from MgmtB to the valid address of FWB2, I get :
Source Destination XlatedSrc XlatedDst
Service
172.25.m.n FWB2_valid MgmtB_valid FWB2_valid
ping-request
FWB2_valid MgmtB_valid FWB2_valid MgmtB_valid ping-reply,
which never arrives at MgmtB !!!
Because I have to use the internal addresses in the network objects FWB1
and FWB2 to workaround this, I expect problems setting up VPN's between
SiteB and other sites (SiteC, SiteD,...)
Second problem
------------------------
When an internet client sends a packet to a valid address on SiteB, the
reply is send back with the internal address of the corresponding server as
source address, not it's valid IP as would be expected.
Both problems seem to be address translation issues, although the address
translation rules are fairly straightforward :
2 rules for each server, and first rule disables NAT between the internal
networks behind the cluster.
I tried several things, including using manual NAT-rules, disabling the
first NAT-rule and upgrading both FWB1 and FWB2 to SP2 (they came with
SP1), but nothing worked.
Any ideas ?
----------------------------------------------------------------------------
--------------------------
Philippe Verdonck
Sr System Engineer
Erudict Antwerpen NV
Desguinlei 250
B-2018 Antwerp
Belgium
----------------------------------------------------------------------------
--------------------------
__________________________________________________
The information in this Internet e-mail is confidential and may be legally
privileged. It is intended solely for the addressee.
Access to this Internet e-mail by anyone else is unauthorized.
If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is prohibited and may be unlawful. When addressed to our clients any
opinions or advice contained in this Internet e-mail are subject to the
terms and conditions expressed in any applicable governing LCI Technology
Group terms of business or client engagement letter.
============================================================================
====
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
============================================================================
====
__________________________________________________
The information in this Internet e-mail is confidential and may be legally
privileged. It is intended solely for the addressee.
Access to this Internet e-mail by anyone else is unauthorized.
If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on it,
is prohibited and may be unlawful. When addressed to our clients any
opinions or advice contained in this Internet e-mail are subject to the
terms and conditions expressed in any applicable governing LCI Technology
Group terms of business or client engagement letter.
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
|
|
