NTP Server behind CSS / Responses from outside don't get through

[jxdemel]

I have a CSS and behind it an NTP-Server (simulated for this posting by the ntpdate-command:

First, when I use ntpdate -q 128.130.2.7 (with the -q parameter a source-port >1024 is used) all wents fine, I get a response and the flow trace-ip shows:

JAN 20 10:12:15 1/1 1187 FLOWMGR-4: UDP in 192.168.7.73:35700->128.130.2.7:123

JAN 20 10:12:15 1/1 1188 FLOWMGR-4: UDP out 128.131.2.73:4724->128.130.2.7:123

JAN 20 10:12:15 1/1 1189 FLOWMGR-4: UDP in 128.130.2.7:123->128.131.2.73:4724

JAN 20 10:12:15 1/1 1190 FLOWMGR-4: UDP out 128.130.2.7:123->192.168.7.73:35700

But when I now use ntpdate 128.130.2.7 without the -q option, i.e. well known Source Port 123 is used, no response come through and the trace-ip shows:

JAN 20 10:13:20 1/1 1194 FLOWMGR-4: UDP in 192.168.7.73:123->128.130.2.7:123

JAN 20 10:13:20 1/1 1195 FLOWMGR-4: UDP out 128.131.2.73:123->128.130.2.7:123

JAN 20 10:13:20 1/1 1196 FLOWMGR-4: UDP in 128.130.2.7:123->128.131.2.73:123

JAN 20 10:13:21 1/1 1197 FLOWMGR-4: UDP in 128.130.2.7:123->128.131.2.73:123

JAN 20 10:13:22 1/1 1198 FLOWMGR-4: UDP in 128.130.2.7:123->128.131.2.73:123

JAN 20 10:13:23 1/1 1199 FLOWMGR-4: UDP in 128.130.2.7:123->128.131.2.73:123

i.e. 128.130.2.7 sends the response to the vip-address and the css receives it, but does not send it to the requesting server.

The relevant configuration parts are (currently ACL is disabled!):

!************************** CIRCUIT **************************

circuit VLAN602

ip address 128.131.2.101 255.255.255.0

ip virtual-router 102 priority 254 preempt

ip redundant-vip 102 128.131.2.72 shared

ip redundant-vip 102 128.131.2.73 shared

ip redundant-vip 102 128.131.2.3 shared

ip critical-service 102 gw-128.131.2

!*************************** GROUP ***************************

group ogawa2

add service ogawa2i

vip address 128.131.2.73

active

!************************** SERVICE **************************

service ogawa2i

ip address 192.168.7.73

active

It looks like, that the response does not comes through, if the source-port of the requesting server uses a port <1024.

Any ideas ??

[Gilles Dufour]

There are some ports for which we do not maitain flow information but 123 should not be one of them.

What software version are you using ?

A workaround could be to create the following content rules :

owner TEST

content NTP

vip address 128.131.2.73

protocol udp

port 123

add service ogawa2i

active

!

Let me know if this works.

Gilles.

[jxdemel]

SW-Version ist sg0710006s. The same problem is in 7.10 Build 3. We have a css11503.

Is there anywhere a list of ports, where flow-information is not maintained.

The above workaround works, but it has the disadvantage, that

now the server/port can be reached from outside as a regular service which may be complicate to block via ACLs.