I have a question regarding source groups used to allow servers behind the Content Switch to initiate connections to the outside.
I understand the concept of creating a source group and adding the services (servers) that will be included within it, and also giving this a VIP address to be used as the source IP for the services connection to the outside world. A content rule is then created for these connections using the same VIP and services as referenced in the source group configuration. It is at this point I have a question regarding the configuration.
Do I have to specify, in the content rule, what protocol and port the services will be using? For instance if I want the servers to be able to make DNS queries, do ftp file transfers, and contact a database is it required that I configure a seperate content rule for each type of connection, or can I make one content rule without specifying what protocol and port to be used, and this would suffice for all types of connections the services try to initiate.
Thanks in advance for any help provided.
You shouldn't need source groups for your servers to initiate connections to the outside world unless you want or need all the traffic to appear as it is coming from a VIP address.
If you do want to use a group, I don't think you need a content rule, but I've never used a group in this way.
Generally, I've used groups to NAT traffic in the other direction (from the client), in one-armed configurations to force the correct return path from the server back to the client. In this configuration, I add destination services to the group to instruct the CSS as to which traffic it should NAT.
Thanks for the quick reply.
What method are you using in order for the servers to initiate connections to the outside? The CSS Basic Guide book uses Source Groups as the method.
As things stand now, the servers are not able to contact outside devices by initiating the connection. They work for connections initiated on the outside to the VIP we use for them, but not in the reverse. The connections appear to die at the Content Switch when initiated from the inside.
You will in fact need to use the source groups in the manner you describe and will need the content rule, however, you could potentially just have the content rule as an L3 rule with just the services and vip address and not specify the protocol or port and leave it wide open.
Could you point me to the doc that shows this as a requirement?
I will be migrating my CSS's to a L3 configuration (The CSS as default gateway for the web pool) soon and this could throw a big wrench in my plans.
The way I interpreted the documentation is that I would only need source groups if I want the servers to appear as one IP address to the rest of the network, or if I need to translate their private address to a public. We do our private/public NAT on a firewall, so I have no public addressing on the CSS itself.
My (perhaps incorrect?) assumption is that the CSS will just route any and all IP traffic normally between interfaces.
I'm not sure there is one. The assumption I make here is that the servers and vips are on different networks. If they are on the same network, then you probably don't need to do this. It becomes an issue when the vip (public) and servers (private) are setup in this manner. Specifically, the packet leaving the server through the CSS goes out. On the return, the packet hits the upstream router and does not have a path back to the CSS as the router (in most cases) is only sending VIP destined traffic to the CSS which is why we would NAT the server request to the VIP. If the upstream router has a static route with the servers network with a next hop of the CSS, then maybe this is not necessary
The configuration task in Basic Configuration Guide(7.20) requires configuring "add service" or "add destination service" in source group(Step 3). However, I saw the following source group configuration from a production network, how does it work.
!*************************** GROUP ***************************
vip address 22.214.171.124
vip address 126.96.36.199
vip address 188.8.131.52
vip address 184.108.40.206
vip address 220.127.116.11
vip address 18.104.22.168
vip address 22.214.171.124
vip address 126.96.36.199
vip address 188.8.131.52
!**************************** ACL ****************************
clause 4 permit icmp 10.0.0.0 255.224.0.0 destination any sourcegroup out1
clause 5 permit any 10.0.0.0 255.224.0.0 destination any sourcegroup out1
clause 6 permit icmp 10.32.0.0 255.224.0.0 destination any sourcegroup out2
clause 7 permit any 10.32.0.0 255.224.0.0 destination any sourcegroup out2
clause 8 permit icmp 10.64.0.0 255.224.0.0 destination any sourcegroup out3
clause 9 permit any 10.64.0.0 255.224.0.0 destination any sourcegroup out3
clause 10 permit icmp 10.96.0.0 255.224.0.0 destination any sourcegroup out4
clause 11 permit any 10.96.0.0 255.224.0.0 destination any sourcegroup out4
clause 12 permit icmp 10.128.0.0 255.224.0.0 destination any sourcegroup out5
clause 13 permit any 10.128.0.0 255.224.0.0 destination any sourcegroup out5
clause 14 permit icmp 10.160.0.0 255.224.0.0 destination any sourcegroup out6
clause 15 permit any 10.160.0.0 255.224.0.0 destination any sourcegroup out6
clause 16 permit icmp 10.192.0.0 255.224.0.0 destination any sourcegroup out7
clause 17 permit any 10.192.0.0 255.224.0.0 destination any sourcegroup out7
clause 18 permit icmp 10.224.0.0 255.224.0.0 destination any sourcegroup out8
clause 19 permit any 10.224.0.0 255.224.0.0 destination any sourcegroup out8
clause 20 permit icmp 184.108.40.206 255.255.0.0 destination any sourcegroup out9
clause 21 permit any 220.127.116.11 255.255.0.0 destination any sourcegroup out9
clause 22 permit icmp 172.16.0.0 255.240.0.0 destination any sourcegroup out9
clause 23 permit any 172.16.0.0 255.240.0.0 destination any sourcegroup out9
clause 24 permit icmp 192.168.0.0 255.255.0.0 destination any sourcegroup out9
clause 25 permit any 192.168.0.0 255.255.0.0 destination any sourcegroup out9
clause 30 permit icmp 18.104.22.168 255.255.255.0 destination any sourcegroup out9
clause 31 permit any 22.214.171.124 255.255.255.0 destination any sourcegroup out9
Would you please clarify me.
this is the other way to do NAT (refer to http://www.cisco.com/en/US/partner/products/hw/contnetw/ps789/products_configuration_example09186a008009470e.shtml) The only bad thing on this method is, that you have to apply acls on all circuits even if a permit any any is necessary as enabling acls stops all traffic from getting forward except the circutis you applied a acl. I would prefer the earlier described method if I won't have to do traffic filtering on the CSS. Another aspect is the bypassing. Afaik bypassing NAT is not possible with add destination service.