I am facing a problem with IBM Datapower XG45.7.0.0.0.
When I am connecting to an external service using DP, the source IP of DP is being picked up randomly among the 3 available eth interfaces. I know this has performance and stability benefits. However, this is causing great deal of pain in the firewall config. As a tactical solution, is there a way to ensure that the traffic is send from any one fixed eth interface?
Sure, normally you should make sure only one NIC has a default gateway (and that would in most cases be the NIC facing the Internet).
The two other NIC's should only have static routes and set for the various subnets they should serve.
If you don't have a need for different IP addresses for outbound (egress) traffic you might want to use only one NIC and set two additional Secondary IP addresses instead.
That way you have three working IP address for ingress (inbound) traffic but only one IP will be used for egress.
Related
I'm exploring alternate multiplicities between IP subnets and VLANs, outside the recommended 1-to-1 implementation. My understanding is as follows:
Multiple subnets to a single VLAN (connected via a switch):
Hosts across both subnets would receive layer 2 broadcasts (such as ARP), but would ignore traffic lacking an IP that targets them.
Question: Would I be able to communicate across subnets without a layer 3 device if I could manually insert a destination MAC address in the frame header? My understanding is that the layer 2 switch is oblivious to the differing subnets, and assuming it knows the location of the destination MAC address, would forward the packet in its direction. The destination PC, seeing its IP and MAC addresses, would accept the packet, effectively letting it cross subnets without ever being routed.
A single subnet across multiple VLANs:
Broadcast traffic would be isolated to the individual VLANs. This would break ARP, as a host targeting another machine in the same subnet (but unknowingly in another VLAN) would send out an ARP request that would never be responded to.
This would effectively create separate, identical address pools for each of the VLANs, though I'm not sure how a router would differentiate between the two when interVLAN communication is attempted. I'm a little bit unsure about the pros/cons of this configuration..
Why would we ever want to do this?
Multiple subnets to a single VLAN (connected via a switch):
Hosts across both subnets would receive layer 2 broadcasts (such as ARP), > but would ignore traffic lacking an IP that targets them.
This actually has it's use case in modern DCs. Not in a way you suggest it (w/o a L3 device), but with a VEPA switch.
A single subnet across multiple VLANs:
Broadcast traffic would be isolated to the individual VLANs. This would break ARP, as a host targeting another machine in the same subnet (but unknowingly in another VLAN) would send out an ARP request that would never be responded to. This would effectively create separate, identical address pools for each of the VLANs, though I'm not sure how a router would differentiate between the two when interVLAN communication is attempted. I'm a little bit unsure about the pros/cons of this configuration..
A single subnet across multiple VLANs, also called Transparent subnet gatewaying (RFC 1027) is a somehow archaic approach. It uses Proxy ARP, but proxy ARP has it's own set of problems.
Multiple subnets to a single VLAN (connected via a switch):
Hosts across both subnets would receive layer 2 broadcasts (such as ARP), but would ignore traffic lacking an IP that targets them.
Question: Would I be able to communicate across subnets without a
layer 3 device if I could manually insert a destination MAC address in
the frame header?
You will need to replace the MAC address, and need to recalculate FCS over the whole frame, else the switch will reject it as a damaged frame. This must happen after your ethernet driver does this.
A single subnet across multiple VLANs:
Broadcast traffic would be isolated to the individual VLANs. This would break ARP, as a host targeting another machine in the same
subnet (but unknowingly in another VLAN) would send out an ARP
request that would never be responded to. This would effectively
create separate, identical address pools for each of the VLANs,
though I'm not sure how a router would differentiate between the two
when interVLAN communication is attempted. I'm a little bit unsure
about the pros/cons of this configuration..
Why would we ever want to do this?
Hosts in the same subnet would not be able to communicate with each other. Most routers will not let you assign the same network to multiple interfaces, unless they are bridged interfaces, in which case, you haven't accomplished anything except sending the traffic the long way around.
Some switches have something similar to this, called Private VLANs, where hosts can only communicate with a gateway. This is a security feature used in some situations.
We are attempting to use a Cisco ASA as a VPN as well as forward traffic to two servers.
Our ISP has given us a range of IP addresses that are sequential.
154.223.252.146-149
default GW of 154.223.252.145, we're using netmask 255.255.255.240
We have the first of these, 154.223.252.146, assigned to the external interface on our ASA and it’s successfully hosting our VPN service. It works great.
The next and final goal is to have 154.223.252.147 forward https traffic to 10.1.90.40 and 154.223.252.148 forward https traffic to 10.1.94.40.
Our current blocker is our inability to get the outside interface of the asa to respond to these ip addresses.
We’ve been able to use 154.223.252.146 to forward https traffic correctly. So we know that works.
I’ve plugged my laptop into the switch from our ISP and have successfully manually assigned 154.223.252.147 and 154.223.252.148 with the default gw of 154.223.252.145 and was happily connected. So we know the IP’s are there and available, we just need to convince the ASA to respond to them and use them to forward https.
We’ve tried plugging cables from the switch into other interfaces on the firewall. This failed because the netmask overlaps with our first outside interface 154.223.252.146 255.255.255.240, Cisco hates this and doesn’t allow it.
We’ve read documentation and have heard that it’s possible to assign a range of IPs to the ouside interface by defining a vlan. We do not know how to successfully make this work and out attempts have failed.
What's the best way to accomplish this configuration with a Cisco ASA?
You don't need to assign multiple IPs from the same range to more than one interface. That doesn't work with Cisco. Instead try a static one to one NAT for your Web server and terminate your VPN traffic on the IP address assigned to the interface.
Watch this video for one to one NAT:
https://www.youtube.com/watch?v=cNaEsZSsxcg
Cisco has an active scanning technology that was enabled on this ASA. We were able to diagnose it by intermittent bad behavior. After troubleshooting long enough we realized that some of the behavior couldn't be consistent with the changes we were making. So we started looking for things that the firewall would be trying to do by itself. That ended up helping us narrow it down. Disabling active scanning allowed our external vlan configurations to work. Now moving on to tightening up the configs.
Can gateway(network device) handle different protocols. I know that it is used to connect dissimilar networks. What type of dissimilarity does it include?
The term Gateway is a very broad term. In Networking a Gateway is typically a device that sits between two network domains or at the entrance to a domain and may handle protocol translations, perform address translations, filter traffic, terminate sessions and much more.
An IP Router for example in some cases is named as a Gateway as it connects the local subnet to the rest of the network - hence the term 'default gateway' you can see on every PC IP settings.
To answer your first Q - a gateway in many cases would handle different protocols.
I have an application that relies on IP addresses for communication (Domain names simply does not work. :(... )
Its function is to connect to its peer on the other machine and send data over after establishing trust. During the "trust establishing" phase they both exchange their IPs for future communication. They both are behind the two different firewalls and are NATted. One is in our NATted office network and other is in the cloud NATted behind their firewall. The applications knows their respective private IPs and exchange that (the 10.x.xxx.xxx range), when they try to connect back to each other (using the private IPs with range 10.x.xxx.xxx) for transferring data they fail. The connection is TCP and the port range is pretty varied.
I am curious if there is anyway I can hard code (for this one time) a rule (at may be firewall level or some place outside my application) that says if there is a connection being initiated for IP address 10.x.xxx.xxx then redirect it to 205.x.xxx.xxx?
Private IP address ranges like 10.x.y.z are, by their very nature, private.
You can't do any meaningful resolution unless each node in between the endpoints has rules in place to translate these.
Translation is tricky, all the main tools you would use cater for static translation (port forwarding, e.g. where a particular port is forwarded to a particular IP). This is one avenue, but it is a hacky one (it requires you to open lots of ports, procedurally update your router and probably have some sort of broker server to maintain mappings).
Alternatively, you could run the isolated networks over a VPN, which would give your endpoints mutual private IPs which you can use to connect to eachother. It would simply be a case of binding to this new address and communicating across the VPN. This would also potentially encrypt your communication over the internet.
Other possibilities are to use NAT/TCP punchthrough techniques which can allow traversal, but these are really a patch to a broken network topology (Read up on IPv6 to see how this can be alleviated).
Alternatively, you could route all the connections over a proxy, but this will complicate matters compared to a VPN.
To answer the question about hardcoding a rule, port forwarding is the solution here. It will obviously depend on your router configuration for the peer accepting the connection, but this client should have the port target port forwarded to the machine. This will obviously not scale very well and is really shifting to a server/client architecture for one connection!
Depending on your hardware, you may be able to forward a range of ports (if a single port cannot be established) and limit the port forwarding to certain incoming connections (the external IPs).
Information on port forwarding can be found at http://portforward.com/
This sounds a lot like what you'd want out of a VPN. Is there anyway that you could set one up? Basically the Site-To-Site VPN between you and the cloud would say 'oh hey, here is an ip located on the remote network, go ahead and connect through the link'. Would this kind of solution work in your case?
Something along these lines: http://i.msdn.microsoft.com/dynimg/IC589512.jpg
I am developing a networked application that runs on a few different computers on a LAN. One of the core needs is for the app to maintain a list of peers on the LAN with which it has communicated in the past, so that it can restore previous sessions. The naive solution would be to just remember the IP and store it in a table, but what happens when the IP of a peer changes?
Instead, I thought I'd store the hostname of the peers so even if the IP changes they will still be reachable via their hostname. (I know hostnames can change as well but that is good enough).
So my question is what exactly is needed to make hostname resolution work on a LAN with mixed Windows/Mac/Linux clients?
Without the use of a central authority the only reliable way to achieve this is through the use of zerconfiguration name resolution. This means that without a multicast router you will only be able to dynamically resolve peers on the same subnet as the resolving host. You could use something like bonjour for mac, netbios or ssdp for windows or avahi for linux but you can't assume that these are enabled. I may be overlooking some more popular protocols that perform this function well but I would personally throw together a quick udp broadcast name resolution protocol for your application. Take a look at these for some more ideas:
Zeroconf Name resolution
Universal local network name resolution method without DNS?
http://en.wikipedia.org/wiki/Zero_configuration_networking#Name_resolution
http://en.wikipedia.org/wiki/Broadcast_address#IP_networking
I would pick a specific udp port to listen on (lets say 12000) and then when you're ready to resolve hosts send a "hello" udp packet out to 255.255.255.255 on port 12000 and all of the other hosts on your network running your app should reply with a packet containing their hostname, possibly other information.