And I don't even think this is Code Red II related (or only
indirectly; I think this is CBOS 2.4.x related, and I performed that
upgrade because of Code Red).
I'm in PPP mode (not bridged) and I've got static IPs. I'm using
Virtual Ethernet Ports (VIP) along with NAT; the internal ethernet
segments are carrying both my static /28 subnet and my private
internal class-A (10.* is so much easier to remember than the class c
one). Thus my two servers are exposed to the wild net (i.e. their
static IPs are routed), but the workstations running on internal
addresses are protected behind NAT. Besides, there are more total
active addresses inside than I have static IPs.
This was working fine under CBOS 2.2.something (the VIP feature
appeared in 2.2, and that's why I upgraded to it).
It stopped working in one particular area with the CBOS 2.4.[1,2]
upgrade (I'm currently running 2.4.2, but was a .1 briefly along the
way).
A workstation (on an internal IP address) can no longer access the
local servers on their public IP address.
I know the mechanism of the failure. What's happening is that the
packet from 10.0.0.221 (workstation) to 63.224.10.73 is being NATted
so that it is now a packet from 63.224.10.78 to 63.224.10.73. This
reaches .73 correctly, and .73 responds with a packet from .73 to
.78. This reaches the router and nothing then happens. After a few
seconds retry attempts begin. Nothing is every accomplished.
I *think* the failure to handle the return packet through NAT properly
is because of the newly added feature that a VIP can be declared
"inside" or "outside" for NAT purposes. Mine are outside (and that's
the default) because the whole point is to NOT perform NAT on traffic
between my static /28 and the outside Internet.
What this means in practice is that we cannot reach the by-name
virtual web servers hosted on the inside servers; which means that I
and the other people living here can't look at the web pages we're
maintaining / developing. For everything else, accessing the servers
by their inside IP addresses works fine (ssh, ftp, X, and so forth).
This is severely annoying to all of us, so I'm under a fair amount of
pressure to find a *fix* for this. (Yes, one workaround that has
occurred to me is to see if I can get the by-name virtual hosting to
respond at multiple IP addresses; see below where I say I want a
solution not a workaround if at all possible, but if I have to fall
back on a workaround this might be one of the better ones.)
I can't find anybody at Qwest (and I'm a pro-DSL customer) who seems
to have the faintest clue about this level of configuration. Heck,
the Cisco documentation doesn't say anything about what *uses* one
might make of VIP, nor does it give any example configurations. I'd
think mine is a common one -- short of a full DMZ, which requires
either another router or a different router (i.e. one with separate
"inside" and "DMZ" ports), my configuration seems to be the obvious
setup for businesses and home offices that want to have a few
publically visible servers, and lots of private inside stuff.
Anybody got any bright ideas on this? Any Cisco 675 experts? (And
just for my curiosity, is there some actual benefit to breaking the
previous behavior that I was using? Does it make something else nifty
keen possible?)
I really want to find a *solution*; I've thought a bit about various
workarounds, and some of them might work, but they all make additional
pieces of hardware or software mission-critical for this network, so
I want to avoid them if at all possible. If I have to give up on
looking for a solution, I'll be back to ask for help shooting at
workarounds I guess :-(.
To be *really* specific, here's some packets:
Packet 1: ddb -> nat
Network: Ethernet
Frame type: 802.3, Frame size: 66
Time: 22h:36m 18.116 000s, Diff. time: 0.000000
Date: Wed Aug 08 2001
IP, 10.0.0.221 -> 63.224.10.73
Source IP: 10.0.0.221 , Destination IP: 63.224.10.73
Version: 04, IP header length: 05 (32 bit words)
Service type: 0: Precedence: 0, Delay: Norm, Throug: Norm,
Reliab: Norm
Total IP length: 48
ID: F3FCh
Fragment flags: [10] - don't fragment - last fragment
Fragment offset: 0
Time to live: 128
PROTOCOL: [6] TCP
Header checksum: B1C5 (GOOD)
TCP SYN, [1553] -> [80]
Source port: [1553] Destination port: [80] http
Sequence number: 82466987, Acknowledgement: 0
TCP header length: 07 (32 bit words), Window: 64240
TCP data length: 0, Checksum: CF32h (GOOD)
TCP options: Maximum segment size= 1460.
Sequence number + TCP data length: 82466987
HTTP Section: 0 bytes
No HTTP data sent with this packet
---------------------------------------------------------------
---------------------------------------------------------------
Packet 2: nat -> ns2
Network: Ethernet
Frame type: 802.3, Frame size: 66
Time: 22h:36m 18.117 000s, Diff. time: 0.001000
Date: Wed Aug 08 2001
IP, 63.224.10.78 -> 63.224.10.73
Source IP: 63.224.10.78, Destination IP: 63.224.10.73
Version: 04, IP header length: 05 (32 bit words)
Service type: 0: Precedence: 0, Delay: Norm, Throug: Norm,
Reliab: Norm
Total IP length: 48
ID: F3FCh
Fragment flags: [10] - don't fragment - last fragment
Fragment offset: 0
Time to live: 127
PROTOCOL: [6] TCP
Header checksum: 7374 (GOOD)
TCP SYN, [10041] -> [80]
Source port: [10041] Destination port: [80] http
Sequence number: 82466987, Acknowledgement: 0
TCP header length: 07 (32 bit words), Window: 64240
TCP data length: 0, Checksum: 6EB9h (GOOD)
TCP options: Maximum segment size= 1460.
Sequence number + TCP data length: 82466987
HTTP Section: 0 bytes
No HTTP data sent with this packet
---------------------------------------------------------------
---------------------------------------------------------------
Packet 3: ns2 -> nat
Network: Ethernet
Frame type: 802.3, Frame size: 66
Time: 22h:36m 18.123 000s, Diff. time: 0.006000
Date: Wed Aug 08 2001
IP, 63.224.10.73 -> 63.224.10.78
Source IP: 63.224.10.73, Destination IP: 63.224.10.78
Version: 04, IP header length: 05 (32 bit words)
Service type: 0: Precedence: 0, Delay: Norm, Throug: Norm,
Reliab: Norm
Total IP length: 48
ID: 0000h
Fragment flags: [10] - don't fragment - last fragment
Fragment offset: 0
Time to live: 64
PROTOCOL: [6] TCP
Header checksum: A671 (GOOD)
TCP SYN ACK, [80] -> [10041]
Source port: [80] http Destination port: [10041]
Sequence number: 2611854893, Acknowledgement: 82466988
TCP header length: 07 (32 bit words), Window: 5840
TCP data length: 0, Checksum: F8EDh (GOOD)
TCP options: Maximum segment size= 1460.
Sequence number + TCP data length: 2611854893
HTTP Section: 0 bytes
No HTTP data sent with this packet
---------------------------------------------------------------
---------------------------------------------------------------
Packet 4: ddb -> nat
Network: Ethernet
Frame type: 802.3, Frame size: 66
Time: 22h:36m 21.039 000s, Diff. time: 2.916000
Date: Wed Aug 08 2001
IP, 10.0.0.221 -> 63.224.10.73
Source IP: 10.0.0.221 , Destination IP: 63.224.10.73
Version: 04, IP header length: 05 (32 bit words)
Service type: 0: Precedence: 0, Delay: Norm, Throug: Norm,
Reliab: Norm
Total IP length: 48
ID: F4FCh
Fragment flags: [10] - don't fragment - last fragment
Fragment offset: 0
Time to live: 128
PROTOCOL: [6] TCP
Header checksum: B0C5 (GOOD)
TCP SYN, [1553] -> [80]
Source port: [1553] Destination port: [80] http
Sequence number: 82466987, Acknowledgement: 0
TCP header length: 07 (32 bit words), Window: 64240
TCP data length: 0, Checksum: CF32h (GOOD)
TCP options: Maximum segment size= 1460.
Sequence number + TCP data length: 82466987
HTTP Section: 0 bytes
No HTTP data sent with this packet
---------------------------------------------------------------
---------------------------------------------------------------
--
David Dyer-Bennet / Welcome to the future! / dd-b at dd-b.net
Photos: http://dd-b.lighthunters.net/
Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/