Raptor and PIX: incompatibility ?

[Christiaan Meihsl <Christiaan.Meihsl () reuters com>]

Hello Wizards,

Can anyone help a non-wizard on a difficult question ?
Note : all IP addresses in this mail have been changed for confidentiality
reasons.

I'm setting up the following test network :

InsideLAN - Raptor ---- 172.17.63.32/27  ---- PIX ---- 193.1.2.0/24 ----
Internet
                              |
               172.17.63.64/27
                              |
                           www

Public IPs are on external PIX interface (Internet) only.
All other IPs are on subnetted unroutable networks.

Routing works fine, tested through pings from www to Raptor, PIX, Internet.
We have rules to allow the www to surf Internet (using the Raptor as proxy),
works fine through the PIX as well.
Other outgoing traffic works fine as well.

Problem is with incoming traffic :

Raptor : UNIX 6.0.2 / Solaris 6.
No spoof-protection, no packet filters, only proxies, maximum logging (103,105 &
121 messages).
External IP : 172.17.63.33
An http proxy listens for traffic sent to it's external interface (PIX side),
and has a redirect for service http from a virtual address (172.17.63.40)
towards the real IP (172.17.63.70) of the www web server.

PIX : 5.2.1
External IP : 193.1.2.1
Listens for http requests from Internet to the www's public IP (193.1.2.3),
translates the destination IP (193.1.2.3) to the virtual address on the Raptor
(172.17.63.40),
and forwards the packets to the Raptor.

I was expecting the Raptor to forward this to the www, but this set-up does not
seem to work !

OK: if I connect a test client PC to the 172.17.63.32 LAN and send an http
request to the virtual IP 172.17.63.40 :
works fine, PC browser displays the home page.
I see the connection in the Raptor's log file (105, 121, 103).
Using snoop on the Raptor's external interface, I can see all the packets (SYN,
ACK, etc).

KO: If I connect the same test PC to the 193.1.2.0 LAN and send an http request
to the virtual IP 193.1.2.3 :
does not work, PC times out.
I see nothing in the Raptor's log file (not even 105 message for connection
init).
But with the same snoop on the Raptor's external interface I can see several SYN
packets coming.
The Raptor just does not seem to react to them, even though destination IP and
MAC are the same
as in the working case.

Looking at the snoops of the packets arriving on the Raptor, in detail:
- Ethernet headers are same except for source MAC (normal).
- IP headers are same except for source IP, identification and checksum
(normal).
- TCP headers are same except :
     - source port, sequence number, checksum (normal),
     - TCP flags for PC on 172.17.63.32 LAN (seem normal) :
       SYN (1st packet)
       ACK (2nd packet)
       ACK PUSH (3rd packet)
       ACK PUSH (4th packet)
       TCP flags for PC on 193.1.2.0 LAN (no change from packet to packet, NOT
NORMAL !)
       SYN flag set on all packets
     - maximum segment size (>>> IS THIS NORMAL ?)
       1460 for PC on 172.17.63.32 LAN, 1380 for PC on 193.1.2.0 LAN
     - acknowledgement number (>>> IS THIS NORMAL ? SEEMS NOT !)
       0 for PC on 172.17.63.32 LAN, 2847523137 for PC on 193.1.2.0 LAN
       Following packets:
       2314698507 for PC on 172.17.63.32 LAN, 2847523137 for PC on 193.1.2.0 LAN
       2314698507 for PC on 172.17.63.32 LAN, 2847523137 for PC on 193.1.2.0 LAN
       2314698800 for PC on 172.17.63.32 LAN, 2847523137 for PC on 193.1.2.0 LAN

The strangest thing is the acknowledgement number, which is never 0 when leaving
the Cisco PIX.

We also had some GSPs open, TCP and UDP. The only one where the connection
worked through
both the PIX and the Raptor was the only UDP GSP, for UDP 138. As UDP is not
connected, seems
related ...

Has anyone heard of such a problem ?
Any ideas how to fix it ?

Grateful for any suggestions, leads, etc ...

Christiaan Meihsl
Reuters SA
Geneva Switzerland
christiaan.meihsl () reuters com


-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr net
http://www.nfr.net/mailman/listinfo/firewall-wizards