According to the e-mail included SUN RPC won't work with NAT for obvious
reason - see the bits marked with ==>.
This is a Big Bad thing as far as I'm concerned ... I mean the RFC about NAT
is around quite a time already, isn't it?
======================================
Gotcha!! (caught RPC in the act).
The AIMS processes communicate their source IP addresses at the RPC packet
level. See formatted snoop data below.
The RPC packet data contains the client's "real" IP address as sent by the
client - according to the RPC data structures specifications there is a
character data representation (string) of the source netid (IP Addr) of the
calling client. It seems to be in approximately the observed position in the
RPC packet as seen at the server in the snoop data.
Hence, the server tries to contact a partner RPC program at the bogus
address.
I do not know if we can overcome this.
Snoop data follows.
Note (a) Source IP address in IP level header =
translated address as known at server
and (b) ASCII formatted source IP address in RPC level user-data =
originating address as known at client
Note - aims_sys is the environment variable OSI_SYSTEM not a hostname
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 1 arrived at 14:53:8.17
ETHER: Packet size = 226 bytes
ETHER: Destination = 8:0:20:ab:77:2c, Sun
ETHER: Source = 0:e0:1e:4d:37:fc,
ETHER: Ethertype = 0800 (IP)
ETHER:
IP: ----- IP Header -----
IP:
IP: Version = 4
IP: Header length = 20 bytes
IP: Type of service = 0x00
IP: xxx. .... = 0 (precedence)
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: Total length = 212 bytes
IP: Identification = 64239
IP: Flags = 0x4
IP: .1.. .... = do not fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 243 seconds/hops
IP: Protocol = 6 (TCP)
IP: Header checksum = 22ac
==> IP: Source address = x.x.3.110, aims_bern (A)
==> IP: Destination address = x.x.25.69, IMSPROD
IP: No options
IP:
TCP: ----- TCP Header -----
TCP:
TCP: Source port = 33000
TCP: Destination port = 647 (Sun RPC)
TCP: Sequence number = 1154684197
TCP: Acknowledgement number = 165307108
TCP: Data offset = 20 bytes
TCP: Flags = 0x18
TCP: ..0. .... = No urgent pointer
TCP: ...1 .... = Acknowledgement
TCP: .... 1... = Push
TCP: .... .0.. = No reset
TCP: .... ..0. = No Syn
TCP: .... ...0 = No Fin
TCP: Window = 8760
TCP: Checksum = 0x4ea6
TCP: Urgent pointer = 0
TCP: No options
TCP:
RPC: ----- SUN RPC Header -----
RPC:
RPC: Record Mark: last fragment, length = 168
RPC: Transaction id = 964911792
RPC: Type = 0 (Call)
RPC: RPC version = 2
RPC: Program = 312345 (?), version = 4, procedure = 4
RPC: Credentials: Flavor = 0 (None), len = 0 bytes
RPC: Verifier : Flavor = 0 (None), len = 0 bytes
RPC:
0: 0800 20ab 772c 00e0 1e4d 37fc 0800 4500 .. .w,...M7...E.
16: 00d4 faef 4000 f306 22ac 8abe 036e c216 ....@.�."....n..
32: 1945 80e8 0287 44d3 1525 09da 62e4 5018 .E....D..%..b.P.
48: 2238 4ea6 0000 8000 00a8 3983 62b0 0000 "8N.......9.b...
64: 0000 0000 0002 0004 c419 0000 0004 0000 ................
80: 0004 0000 0000 0000 0000 0000 0000 0000 ................
96: 0000 0000 001b 0000 0000 0000 038e 0000 ................
==> 112: 0008 6169 6d73 5f73 7973 0000 000c 3137 ..aims_sys....17
==> 128: 322e 3236 2e31 382e 3834 0000 0000 0000 2.26.18.84......
(B)
144: 0519 0000 0000 0000 0008 6169 6d73 5f73 ..........aims_s
160: 7973 0000 0000 0000 0000 0000 0000 0000 ys..............
176: 0000 0000 0000 0000 001c 0000 0000 3985 ..............9.
192: 85fd 0000 001c 0231 3033 1c61 696d 735f .......103.aims_
208: 7379 732e 3237 3632 2e69 706d 6854 6f6f sys.2762.ipmhToo
224: 6c03 l.
#
Jeroen van Dongen
Uninet network manager
AUCS Communication Services
an infonet managed company
tel: +31 (0) 23 569 7823
fax: +31 (0) 23 569 7771
-----Original Message-----
From: Rodney Lacroix [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 01, 2000 4:51 PM
To: [EMAIL PROTECTED]
Subject: [FW1] Clear Encryption - what are the risks?
I have an Oracle web application running behind my firewall, that I'm
attempting to run via SecuRemote. The only way I can actually get it to
work is to change my user encryption properties to the following:
Session: FWZ1 (anything works)
Data: Clear
Data Integrity method: none
If I change the data to "Any" or specify an encryption method, it does not
work. Conversely, if I leave the data field as "clear" but change the
integrity method field to MD5, that doesn't work either.
If I'm using Client Encryption, what is my risk on leaving the user
encryption set as above? Any help is greatly appreciated.
Rodney Lacroix
============================================================================
====
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
============================================================================
====
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
