Doing Source IP address NAT. Using 1 address vs using many

I have a few implimentations where I am using source groups to do NAT on the client's source IP address. It is possible to always translate the source IP address to the same one, or to have it be different depending on the content rule you hit.
Is there any advantage of one over the other?

Thanks for the thoughts. I am aware of the content rule limitation, and actually, (depending on your definition of PAT vs NAT) the CSS can do NAT of the source IP address using source groups and an ACL. It can translate the source IP address of an incoming packet from a client into a different IP address. You don't really have a pool of addresses like you do on a Cisco router, you can specify a single IP address to translate the source address to, or different ones depending on the content rule you hit, so it is kind of like NATing with overload on a router. I am doing it now.
The basic steps for doing NAT on the source(I.E.-Client's) IP address are:
group [groupx]
ip address [source address you want to change client IP to]
active
acl 1
clause 10 permit any any destination [VIP of content rule] sourcegroup [groupx]
apply circuit-(VLANx)
If the inbound packet on VLANx matches all the criteria in the clause statement, the "sourcegroup" part of the clause statement links you to the ip address that you want to NAT your client's source address to.
You can build on this and make it as fancy as you like, even translating the source address to different addresses depending on the content rule you hit. I'm just wondering if there is an advantage of using many different IP addresses over using just one.

Similar Messages

  • Limitation on source group with services using ip address range

    Hello,
    I have an interface on CSS which I regard as public and another interface I regard as private. On the private interface is a server farm with private ip addresses. Since the server admin guys insisted the servers need to access internet just for Windows Update, I made a source group to NAT the private addresses to public addresses to allow the servers to access internet.
    I defined services for use by the source group. Since keepalive is not important in this case, I set keepalive none to ,I hope so, save system resources.
    I have server 192.168.1.1-5 (5 servers) and 192.168.1.11-14 (4 servers), so I made a service with ip address 192.168.1.1 range 5 and another service 192.168.1.11 range 4.
    But then I found that the two services cannot be put in the same source group. It is because of the different range in the service definition.
    I can get it work if I define services with single ip address, but then I will have a long configuration with repetative information. And I think this may be using more system resources.
    I can also get it work if I include 192.168.11.15 and define two services both with a range of 5 ip addresses. But 192.168.11.15 is not actually there.
    Why is there such a limitation on source group, or services with ip address range? Is there the same limitation for content rules? Or am I getting it all wrong and should do the configuration in other ways?
    Advices will be welcomed.
    CT Yau
    Hong Kong

    Yes you are correct. There is a limitation while adding services into source groups.
    You can create as many services that share an ip range (eg. a /24 subnet range). But the trouble starts when you add them into source groups. You can not add them into a source group NOR you can add them under different source groups as well.
    You mentioned that you can use single ip adress instead of range for the services...but it is not true as you will be stuck when you add them into source groups.
    I can think of these following options in your case.
    Option 1
    Change the ip range on the servers. Use 2 different IP ranges one for those 5 servers and another for those 4 servers.
    Create 2 services for each range.
    Create 2 groups and add the services.
    service server-out-192.168.1.1-5
    ip address 192.168.1.1 range 5
    active
    service server-out-172.168.1.11-14
    ip address 192.168.1.11 range 4
    active
    group server-out-192.168.1.11-14
    vip address x.x.x.1
    add server-out-192.168.1.1-5
    active
    group server-out-172.168.1.11-14
    vip address x.x.x.2
    add server-out-172.168.1.11-14
    active
    Option 2
    Create a service that includes all the ip addresses starting from 192.168.1.1 through .14 using the range keyword.
    Now you need to create one source group with a VIP. Add the service to the source group.
    If you do not want to cover the unassigned ip addresses just move them up and use consecutive ones.
    service server-out-192.168.1.1-14
    ip address 192.168.1.1 range 14
    active
    group server-out-192.168.1.11-14
    vip address x.x.x.x
    add service server-out-192.168.1.1-14
    active
    thanks

  • Ip igmp snooping querier on Nexus, what source IP address to use?

    Am looking at a problem with servers in the same vlan across multiple switches that are unable to communicate using multicast. I have found that in the systen I'm to set up I need to apply the ip igmp snooping querier command, in the vlan, but it needs a source IP address.
    Different documents make conflicting recommendations for this address, one suggests that any unused address will do, another suggests to use the IP address that is configured on the SVI for the vlan.
    Which is correct?

    Eventually I had to ask Cisco TAC, the response was that any IP address within the subnet could be used. The recommendation was to allocate an unused address in the vlan subnet for this purpose, use the same address on multiple switches should resiliance be required.

  • ISCSI Initiator favourites revert to using the IPv6 or the apipa IP address from other NICs instead of the source IP address that I specified

    Windows 2008 R2
    ISCSI Initiator favourites revert to using the IPv6 or the apipa IP address from other NICs instead of the source IP address that I specified. 
    When I manually connect to multiple targets and specify the correct ISCSI source IP address, I check the favourites and everything looks okay. But when the server is rebooted I check the favourites again and the source IP is now referencing the IPv6 and
    sometimes the apipa address. 
    I have unbound IPv6 from the ISCSI NICS but this has made no difference.
    Can anyone explain why this is happening?
    Although the server still reconnects to the storage oaky, I’m concerned that if a path goes down that is might try to use the wrong interface to re-establish a connection.
    Thanks.  

    Hi,
    IPV6 is supported with MS iSCSI. Do you have Multiple Connections per Session (MCS) configured? Is your storage configured to use both IPv4 and IPv6?
    If yes, please see if http://support.microsoft.com/kb/2014131 helps.
    Hope this helps.
    We
    are trying to better understand customer views on social support experience, so your participation in this
    interview project would be greatly appreciated if you have time.
    Thanks for helping make community forums a great place.

  • VRF selector using PBR or Source IP address

    Could anyone can tell which is the better choice of VRF selector using PBR or Source IP address? From Cisco doc, VRF selection based on Source take advance over PBR. My feeling is that PBR may match more criterias than just match source IP address.
    Thanks

    I would personally use the "VRF selection based on source IP address" only where the "VRF selection using PBR" is not available since the latter is a superset of the former.
    Hope this helps,

  • I am using Quickbooks Pro with my macbook pro. It does not allow me to use the @ symbol when I am inputting an email address into the client information section. What do I do?

    I am using Quickbooks Pro with my macbook pro. It does not allow me to use the @ symbol when I am inputting an email address into the client information section. What do I do?

    stefani88 wrote: It seems from other discussions my current OS on my laptop is the reason why it won't sync but people running older versions of windows aren't having a problem. So I don't get it.
    Oh. Gosh.  What's Windows got to do with anything? You're on Leopard, on a Mac.
    It seems from other discussions my current OS on my laptop is the reason why it won't sync

  • HT2486 i created a group in address book and when wanted to use it it does not allow me to use it in email how do use a group name i created?

    I created a group in address book and wanted to use it, it does not allow me to use it in email how do I use a group name i created?

    How many in the group? Some ISP's have a restriction on that. Check with your ISP.

  • Tracing TCP Source/Destination Addresses/Ports for ongoing connections

    On Solaris 10 U4 through U7, I'm trying the following just to perform basic tracking of TCP source/destination addresses and ports, using code similar to what is available in tcpsnoop_snv and tcptop_snv.
    The odd thing is that the addresses/ports appear to be zeroed out - are they being cached outside of the conn_t data structure?
    #!/usr/sbin/dtrace -Cs
    #pragma D option switchrate=10hz
    #pragma D option bufsize=512k
    #pragma D option aggsize=512k
    #include <sys/file.h>
    #include <inet/common.h>
    #include <sys/byteorder.h>
    #include <sys/socket.h>
    #include <sys/socketvar.h>
    /* First pass, for all TCP Read/Write actions, collect source/destination
       IP + Port - after a few secs, print them all out */
    fbt:ip:tcp_send_data:entry
      /* Outgoing TCP */
      self->connp = (conn_t *)args[0]->tcp_connp;
    fbt:ip:tcp_rput_data:entry
      /* Incoming TCP */
      self->connp = (conn_t *)arg0;
    fbt:ip:tcp_send_data:entry,
    fbt:ip:tcp_rput_data:entry
    /self->connp/
      /* fetch ports */
    #if defined(_BIG_ENDIAN)
      self->lport = self->connp->u_port.tcpu_ports.tcpu_lport;
      self->fport = self->connp->u_port.tcpu_ports.tcpu_fport;
    #else
      self->lport = BSWAP_16(self->connp->u_port.tcpu_ports.tcpu_lport);
      self->fport = BSWAP_16(self->connp->u_port.tcpu_ports.tcpu_fport);
    #endif
      /* fetch IPv4 addresses */
      this->fad12 =
        (int)self->connp->connua_v6addr.connua_faddr._S6_un._S6_u8[12];
      this->fad13 =
        (int)self->connp->connua_v6addr.connua_faddr._S6_un._S6_u8[13];
      this->fad14 =
        (int)self->connp->connua_v6addr.connua_faddr._S6_un._S6_u8[14];
      this->fad15 =
        (int)self->connp->connua_v6addr.connua_faddr._S6_un._S6_u8[15];
      this->lad12 =
        (int)self->connp->connua_v6addr.connua_laddr._S6_un._S6_u8[12];
      this->lad13 =
        (int)self->connp->connua_v6addr.connua_laddr._S6_un._S6_u8[13];
      this->lad14 =
        (int)self->connp->connua_v6addr.connua_laddr._S6_un._S6_u8[14];
      this->lad15 =
        (int)self->connp->connua_v6addr.connua_laddr._S6_un._S6_u8[15];
    /* At this point, this->{f|l}ad1{2345}->connua_v6addr.connua_{f|l}addr._S6_un.S6_u8
        are empty - where is this data? */
    }

    http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/css11500series/v7.50/command/reference/CmdGrpC.html#wp1139667
    portmap [base-port base_number|disable|enable|number-of-ports number|vip-address-range number]
    disable
    Instructs the CSS to perform Network Address Translation (NAT) only on the source IP addresses and not on the source ports of UDP traffic hitting a particular source group. This option does not affect TCP flows.
    For applications with high-numbered assigned ports (for example, SIP and WAP), we recommend that you preserve those port numbers by configuring destination services in source groups. Destination services cause the CSS to NAT the client source ports, but not the destination ports.
    Note If you disable flows for a UDP port using the flow-state table and configure the portmap disable command in a source group, traffic for that port that matches on the source group does not successfully traverse the CSS.
    The CSS maintains but ignores any base-port or number-of ports (see the options above) values configured in the source group. If you later reenable port mapping for that source group, any configured base-port or number-of ports values will take effect. The default behavior for a configured source group is to NAT both the source IP address and the source port for port numbers greater than 1023.
    There is no possibility to disable it for TCP.
    We need to source nat the port to guarantee that the server response comes back on the same module/CPU and the internal packet allocation algorithm is based on src and dst ports.µ
    Gilles:

  • Redirect based on source IP address????

    I have a site that I don't want our competitors to view! By
    tracking code, I have managed to obtain their source IP addresses.
    After looking around, there is a .php solution to my problem
    but my host is not well suited to .php files (although it does some
    processing).
    My pages are in .shtml (to process css drop-down menus
    correctly) and I understand that this attached code, if put at the
    top of the page before anything else, will work.
    I have managed to get one working
    http://www.donbur.co.uk/gb/newindex.php
    but am having difficulty getting this code to work elsewhere.
    The problem is, when I try to put this code into either a
    template or as an include, it won't process correctly or the page
    won't render at all.
    Do I have to use .php files or can I insert php script into
    an .shtml document.
    Getting really confused now.... HELP

    Thanks for the constructive advice...
    quote:
    >After looking around, there is a .php solution to my
    problem but my host is not well
    >suited to .php files (although it does some processing).
    What does this mean? Does your hosting plan include php
    support or not?
    You can't just put a php script into any page. It needs to be
    a .php page or you need to reconfigure the server to parse other
    pages for php. But if your hosting plan doesn't support php then it
    won't work in any case.
    My host is BT Internet and they claim not to process .php
    files which is why our main .php site is hosted elsewhere; however,
    it seems that, although it has difficulty (to clarify: doesn't
    render) with main full scripts, it does seem to process simple
    <?php echo commands for example.
    It has been suggested on another forum that the .shtml files
    are set to be recognised by .php in the cpanel but our host will
    not do this...
    Our competitors are not particularly smart or up-to-date and
    this would have been reasonably effective; however, I bow to better
    judgement and close this topic.

  • Load balancing based on source IP address

    Hi,
    I configured a CSS to balance the load depending on source IP address to suppport a application feature in the server.
    We have two firewalls and behind we have different users. We have also two servers behind the CSS.
    Firewalls perform NAT with a unique outside IP address. So, for example, in these conditions the CSS balances requests coming from FW 1 to server 1 and requests coming from FW 2 to server 2. Is it correct this scenario?
    Is it possible that requests coming from FW 1 could be forwarded to Server 2 and viceversa?
    Could anyone answer me?
    Thanks in advance.
    Best regards.
    Giuseppe.

    Giuseppe,
    it all depends on how you configured your CSS.
    Did you use an ACL to force traffic from SRC1 to server1 and traffic from SRC2 to server2 ?
    Or did you simply configure sticky based on source ip or a source ip hash loadbalancing ?
    Except the ACL, all other methods do not guarantee that the traffic will be splitted in 2.
    Gilles.

  • Log connection attempts and source IP address for connections that fail/timeout on RADIUS

    How can I log the connection attempts and source IP address for connections that fail RADIUS authentication?  I'm using RD Gateway on 2012 R2 in conjunction with Azure Multi-Factor Authentication Server on another 2012 R2 server.  When a user fails
    multifactor authentication or the authentication times out, all I get is Security event 6273 on the RD Gateway that the radius server did not process the request, and only the radius server's IP is logged.  There's nothing logged in TerminalServices-Gateway\Operational
    because the TS Gateway hasn't yet processed the connection attempt (all auditing options for RD Gateway are enabled).  The MFA/Radius Server is only logging the connection from the TSGateway - it doesn't know the original client's IP address.
    I'm looking for the equivalent of an IIS log - somewhere the RD Gateway should log the initial HTTPS connection attempt and the source IP address of the client.  I need to be able to track down potentially fraudulent login attempts. 

    Hi,
    Thank you for your posting in Windows Server Forum.
    This error might be caused by one of the following conditions:
    •  The user does not have valid credentials
    •  The connection method is not allowed by network policy
    •  The network access server is under attack
    •  NPS does not have access to the user account database on the domain controller
    •  NPS log files or the SQL Server database are not available
    To perform these procedures, you must be a member of Domain Admins.
    Please check for more information:
    Event ID 6273 — NPS Authentication Status
    http://technet.microsoft.com/en-us/library/cc735399(v=ws.10).aspx
    Hope it helps!
    Thanks.
    Dharmesh Solanki

  • Source ip address for icmp messages not what is expected

    We have a router that has interfaces in multiple VRFs.  One interface sits on an interface that is routed on the Internet.  Other interface sits on a VRF that is in a private address space and is used for WAN connectivity.  The strange behavior that I'm seeing is related to icmp messages coming off the router.  It appears that scanners hitting the Internet-facing interface cause the router to generate icmp messages (type 3) that are source using the IP address of the WAN-facing interface and they are routed across the WAN, into our data center and dropped by our firewall due to anti-spoofing rules.  Is this normal behavior?  Doesn't seem normal to me. Is this behavior something that can be changed via configuration?

    probabaly some body attacking you
    you need inbound access-list in Internet-facing interface.
    and you need to filtr private source addresses classes  A, B, C 
    ip access-list extended InWorld
     deny   ip any 192.168.0.0 0.0.255.255
     deny   ip any 172.16.0.0 0.15.255.255
     deny   ip any 10.0.0.0 0.255.255.255
     permit ip any any
    interface FastEthernet0
     description Internet-facing interface
     ip address 9.2.3.6 255.255.255.252
     ip access-group InWorld in
    later you will see hit counts
    sh access-lis
    here is detailed explanation
    http://www.techrepublic.com/article/prevent-ip-spoofing-with-the-cisco-ios/
    they using more complicated acces-list
    In a typical IP address spoofing attempt, the attacker fakes the source of packets in order to appear as part of an internal network. David Davis tells you three ways you can make an attacker's life more difficult&mdash;and prevent IP address spoofing. 
    As you know, the Internet is rife with security threats, and one such threat is IP address spoofing. During a typical IP address spoofing attempt, the attacker simply fakes the source of packets in order to appear as part of an internal network. Let's discuss three ways you can protect your organization from this type of attack.
    Block IP addresses
    The first step in preventing spoofing is blocking IP addresses that pose a risk. While there can be a reason that an attacker might spoof any IP address, the most commonly spoofed IP addresses are private IP addresses (RFC 1918) and other types of shared/special IP addresses.
    Here's a list of IP addresses—and their subnet masks—that I would block from coming into my network from the Internet:
    10.0.0.0/8
    172.16.0.0/12
    192.168.0.0/16
    127.0.0.0/8
    224.0.0.0/3
    169.254.0.0/16
    All of the above are either private IP addresses that aren't routable on the Internet or used for other purposes and shouldn't be on the Internet at all. If traffic comes in with one of these IP addresses from the Internet, it must be fraudulent traffic.
    In addition, other commonly spoofed IP addresses are whatever internal IP addresses your organization uses. If you're using all private IP addresses, your range should already fall into those listed above. However, if you're using your own range of public IP addresses, you need to add them to the list.
    Implement ACLs
    The easiest way to prevent spoofing is using an ingress filter on all Internet traffic. The filter drops any traffic with a source falling into the range of one of the IP networks listed above. In other words, create an access control list (ACL) to drop all inbound traffic with a source IP in the ranges above.
    Here's a configuration example:
    Router# conf t
    Enter configuration commands, one per line.  End with CNTL/Z.
    Router(config)# ip access-list ext ingress-antispoof
    Router(config-ext-nacl)# deny ip 10.0.0.0 0.255.255.255 any
    Router(config-ext-nacl)# deny ip 172.16.0.0 0.15.255.255 any 
    Router(config-ext-nacl)# deny ip 192.168.0.0 0.0.255.255 any 
    Router(config-ext-nacl)# deny ip 127.0.0.0 0.255.255.255 any
    Router(config-ext-nacl)# deny ip 224.0.0.0 31.255.255.255 any
    Router(config-ext-nacl)# deny ip 169.254.0.0 0.0.255.255 any     
    Router(config-ext-nacl)# permit ip any any     
    Router(config-ext-nacl)# exit
    Router(config)#int s0/0
    Router(config-if)#ip access-group ingress-antispoof in
    Internet service providers (ISPs) must use filtering like this on their networks, as defined in RFC 2267. Notice how this ACL includes permit ip any any at the end. In the "real world," you would probably have a stateful firewall inside this router that protects your internal LAN.
    Of course, you could take this to the extreme and filter all inbound traffic from other subnets in your internal network to make sure that someone isn't on one subnet and spoofing traffic to another network. You could also implement egress ACLs to prevent users on your network from spoofing IP addresses from other networks. Keep in mind that this should be just one part of your overall network security strategy.
    Use reverse path forwarding (ip verify)
    Another way to protect your network from IP address spoofing is reverse path forwarding (RPF)—or ip verify. In the Cisco IOS, the commands for reverse path forwarding begin with ip verify.
    RPF works much like part of an anti-spam solution. That part receives inbound e-mail messages, takes the source e-mail address, and performs a recipient lookup on the sending server to determine if the sender really exists on the server the message came from. If the sender doesn't exist, the server drops the e-mail message because there's no way to reply to the message—and it's very likely spam.
    RPF does something similar with packets. It takes the source IP address of a packet received from the Internet and looks up to see if the router has a route in its routing table to reply to that packet. If there's no route in the routing table for a response to return to the source IP, then someone likely spoofed the packet, and the router drops the packet.
    Here's how to configure RPF on your router:
    Router(config)# ip cef
    Router(config)# int serial0/0
    Router(config-if)# ip verify unicast reverse-path
    Note that this won't work on a multi-homed network.
    It's important to protect your private network from attackers on the Internet. These three methods can go a long way toward protecting against IP address spoofing. For more information on IP address spoofing, read "IP Address Spoofing: An Introduction."
    Is IP address spoofing a major concern for your organization? What steps have you taken to protect the company? Have you used RPF? Share your experiences in this article's discussion.
    and dont forget to rate post

  • The maximum number of connections per source ('20') for this connector has been reached by this source IP address

    Receive connector 'Connector Name' rejected an incoming connection from IP address "IP of our load balancer". The maximum number of connections per source ('20') for this connector has been reached by this source IP address.
    I understand that I can up the limit - however, I'm wondering if there is a way to up the limit for ONE specific IP (our load balancer)
    TAG

    It does not look like you can up the limit for a specific IP but you might be able to create a separate receive connector for that IP address (and then change the limit).
    That is just a thought. Others may have more input on why you may or may not want to do that in practice.
    What SMTP traffic would not be coming from the load balancer?
    Is the objective to *not* allow some other (possibly malicious) source from creating excessive connections to the server?
    Otherwise, this is a good discussion about the different parameters that must be considered if you do decide to adjust the values (changing one may not suffice):
    http://letsexchange.blogspot.com/2012/04/receive-connector-rejected-incoming.html
    Nuno Mota's blog (MVP)
    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

  • Jdbc connection set source ip address

    Hi
    Is there any way to specify the local (source) ip address of a jdbc connection ?
    I work in an enterprise environment with firewalls all over, and only certain ip addresses can connected to other ip addresses.
    The server which runs my application has many ip addresses and
    I'd like to be sure that my ip address is the source...
    Thanks
    Gabor Dolla
    Budapest, Hungary

    No, certainly not in the JDBC API. I don't believe there's even a way to do this in the java.net Socket API. There's the very slimmest of slim chances that a particular driver might implement something like this, in which case it would be in the driver's documentation. However, the chances are so slim that I'd bet strongly against any driver doing this.
    The source address is usually picked by the operating system, based on the routability to the target IP address. Basically, the OS network services looks at the target IP and says to itself, "which (logical) interface can get there? That's the source IP I will use". If your host's routing says there are multiple routes to the IP, then it will pick one; if there's only one route to the particular IP, there will be only one interface (and therefore source IP) that can be chosen.
    There's no reason Java or a driver couldn't be extended to do this, but no particular demand either; the problem is usually dealt with at the network layer.

  • Source Ip Address of Logging Sendmail

    Hi,
    I'm looking for a way to configure a specific Circuit Vlan #'s Ip Address as source ip address of log messages sent as result of the "logging sendmail" command. (at the moment Sw Version: 7.30).
    Does anyone know a way get it ?
    Thanx in advance !
    Francesco

    Francesco,
    This info will come from the mgt ip address assigned on the CSS. You would need to change the mgt ip address on your box which will sendmail will then use:
    Like this:
    CS503# config
    CS503(config)# b
    boot Enter BOOT configuration mode
    bridge Bridge parameters
    bypass Configure Bypassed Service Action
    CS503(config)# boot
    CS503(config-boot)# ip address ?
    Of the form a.b.c.d
    CS503(config-boot)# ip address
    Keep in mind that you do not want to use a circuit ip address range already being used on your CSS.
    Regards
    Pete..

Maybe you are looking for