[f-nsp] ServerIron XL not translating SLB response addresses?

[Brent Van Dussen]

Try putting

'server router-ports 1' (or whatever port connects to the internet where 
client requests will be coming from)

-Brent


At 03:21 PM 1/28/2004, Clifton Royston wrote:
>   I recently picked up a ServerIron XL and put it onto a new network
>I'm setting up, and then plugged in and configured a number of real
>servers behind it and set up some virtual servers on it.
>
>   When I try to connect to the virtual servers, it appears I'm seeing
>quite different behavior in terms of packet rewriting than I see on my
>other ServerIrons, which are essentially identically configured in what
>I thought were the relevant respects.  Even though I have not
>configured DSR, the responses from the real servers are not having
>their source IP address rewritten as I think they should.
>
>   The old ServerIrons and ServerIron XLs are running 7.1.21 or 7.1.08
>(really old!) and the problem ServerIron XL was initially running
>7.3.00, but I also booted it into 7.1.17 (from the secondary) and still
>see the same behavior.
>
>   Here's a config excerpt (names and addresses altered):
>
>ver 07.3.00T12
>no global-stp
>!
>!
>!
>!
>server real real01 10.11.12.49
>  port default disable
>  port smtp
>  port ssl
>  port http
>  port http url "HEAD /"
>!
>server real real02 10.11.12.50
>  port default disable
>  port http
>  port http url "HEAD /"
>  port ssl
>  port smtp
>!
>...
>server virtual virtual01 10.11.12.12
>  sym-priority 100
>  port default disable
>  port smtp
>  bind smtp real02 smtp real01 smtp
>!
>...
>
>!
>!
>enable telnet password .....
>enable super-user-password .....
>enable port-config-password .....
>enable read-only-password .....
>hostname newxl
>ip address 10.11.12.9 255.255.255.192
>ip default-gateway 10.11.12.1
>...
>
>   As you can see, I've made the configuration as vanilla as possible.
>
>   Here's a tcpdump from a client machine, again with names changed to
>protect the innocent:
>
>[client$ telnet virtual01.example.com smtp]
>
>12:10:07.473353 client.example.net.49607 > virtual01.example.com.smtp:
>S 3339122030:3339122030(0) win 8192 <mss 1460,nop,wscale 
>0,nop,nop,timestamp 114
>6543 0> (DF) [tos 0x10]
>12:10:07.473356 real01.example.com.smtp > client.example.net.49607: S 3937
>812647:3937812647(0) ack 3339122031 win 57344 <mss 1460,nop,wscale 
>0,nop,nop,tim
>estamp 69348795 1146543> (DF)
>12:10:07.473357 client.example.net.49607 > real01.example.com.smtp: R 3339
>122031:3339122031(0) win 0
>12:10:09.183449 client.example.net.49607 > virtual01.example.com.smtp:
>S 3339122030:3339122030(0) win 8192 <mss 1460,nop,wscale 
>0,nop,nop,timestamp 114
>6546 0> (DF) [tos 0x10]
>12:10:09.183450 real01.example.com.smtp > client.example.net.49607: S 4170
>5827:41705827(0) ack 3339122031 win 57344 <mss 1460,nop,wscale 
>0,nop,nop,timesta
>mp 69350505 1146546> (DF)
>12:10:09.183451 client.example.net.49607 > real01.example.com.smtp: R 3339
>122031:3339122031(0) win 0
>12:10:13.183649 client.example.net.49607 > virtual01.example.com.smtp:
>S 3339122030:3339122030(0) win 8192 <mss 1460,nop,wscale 
>0,nop,nop,timestamp 114
>6554 0> (DF) [tos 0x10]
>12:10:13.183658 real02.example.com.smtp > client.example.net.49607: S 5
>17189916:517189916(0) ack 3339122031 win 57344 <mss 1460,nop,wscale 
>0,nop,nop,ti
>mestamp 71049339 1146554> (DF)
>12:10:13.183659 client.example.net.49607 > real02.example.com.smtp: R 3
>339122031:3339122031(0) win 0
>12:10:21.184049 client.example.net.49607 > virtual01.example.com.smtp:
>S 3339122030:3339122030(0) win 8192 <mss 1460,nop,wscale 
>0,nop,nop,timestamp 114
>6570 0> (DF) [tos 0x10]
>12:10:21.184051 real02.example.com.smtp > client.example.net.49607: S 2
>177638732:2177638732(0) ack 3339122031 win 57344 <mss 1460,nop,wscale 
>0,nop,nop,
>timestamp 71057341 1146570> (DF)
>12:10:21.184052 client.example.net.49607 > real02.example.com.smtp: R 3
>339122031:3339122031(0) win 0
>  [etc.]
>
>   You can see that the real server responses are not getting rewritten,
>as if I'd specifically enabled DSR, but it's not enabled.  In fact, the
>valid responses from the real server indicate that the initial
>destination IP and MAC addresses are rewritten correctly by the
>ServerIron to reach the real server.  The ethernet interfaces of the
>real01 and real02 servers are physically plugged in directly to the
>ServerIron, so there should be no possibility of their responses taking
>an alternate path which does not pass through it for the standard SLB
>address translation.  The problem occurs when connecting from clients
>both within and outside the ServerIron and servers' subnets, both
>directly connected to it and "upstream" of it as in this example.
>
>   I'm baffled.  I've reread all the docs in the last couple days, and
>those I have seem to say that it should absolutely be rewriting the
>source IP address on these responses, as my past experience showed.  Am
>I missing something obvious here?  My last resort is to enable the
>virtual IP addresses on a loopback, explicitly turn on DSR, and hope
>that works, but I am concerned that I've set up a network with a
>critical piece of equipment which is behaving completely differently
>from what the docs say and how I always thought it should work.
>
>   Guru advice welcomed.
>   -- Clifton
>
>--
>           Clifton Royston  --  cliftonr at tikitechnologies.com
>          Tiki Technologies Lead Programmer/Software Architect
>Did you ever fly a kite in bed?  Did you ever walk with ten cats on your head?
>   Did you ever milk this kind of cow?  Well we can do it.  We know how.
>If you never did, you should.  These things are fun, and fun is good.
>                                                                  -- Dr. Seuss
>_______________________________________________
>foundry-nsp mailing list
>foundry-nsp at puck.nether.net
>http://puck.nether.net/mailman/listinfo/foundry-nsp