I have two servers : server A and server B.
Another company has server C and ASA FW.
I have established an IPsec Tunnel between Server B and the ASA firewall on the remote peer.
Now I need to make server A to connect to server C through the tunnel I established using Server B .
Can this be done using iptables, what are the required rules?
Note we are dealing here with only public ip addresses ( no NAT ).
Thanks for help
If you are not doing any NAT anywhere in the chain, you will need to set up server A to route to the network that server C is on via server B, so that packets from server A to server C will pass through server B. Likewise, you will need to make sure that any packets from server C to server A are directed through the VPN tunnel to server B.
Since you are using IPsec, you will need to make sure that you have the proper phase 2 definitions set up.
Related
I have a rack with Supermicro servers each with IPMI interface. I am able to connect to any IPMI web/cli interface from my notebook. I am also able to ping any IPMI interface from any Supermicro server except the Supermicro server, where the IPMI interface is.
An example of a better explanation of my problem:
servers A, B, C can ping IPMI interface of server D, but server D can't ping IPMI interface of server D
servers B, C, D can ping IPMI interface of server A, but server A can't ping IPMI interface of server A
and so on
It looks like each IPMI interface discards packets from a NIC from the same server where IPMI is. Does anybody know why? I don't see any settings or restrictions on any IPMI interface.
I need it for SNMP. I want to get info like by ipmitool sdr but over SNMP.
That is because supermicro servers uses shared NC-SI connections. NC-SI means network controller sideband interface and it allows to share one physical network interface by operating system running on the host and by BMC. I do not know exact model of your supermicro servers but it is pretty clear it has NC-SI connection like that:
IPMI interface does not discard any traffic from the server because it simply does not receive that traffic. NC-SI means the physical NIC and LAN connector are shared by BMC and CPU. So what happen when you send a request from the host OS to the BMC in the same server?
The host OS knows IP address so it starts with MAC address search via ARP. OS creates an ARP request with a broadcast destination MAC and pass it to the network interface card.
Network interface card sends the ARP request to the network switch.
The switch forwards the ARP request to all ports except the port where the request was received.
Nobody replies to the ARP request because BMC has not received anything.
A few workarounds can be applied:
Use IPMI over IPMB instead of IPMI over IP when connecting to local BMC.
Assign BMC and server IP addresses from different IP ranges or different VLANs and force L3 routing for the traffic between server and its BMC.
Buy a dedicated BMC NIC. Some server models allow that.
If server A receives a UDP packet, can it forward it to server B and have server B directly respond to the end client without going back through server A since UDP is connectionless?
My gut feeling is no, unless both server A and server B have the same IP address (anycast maybe?)
But if the client is built to also be a UDP server, it could work in theory since the (logical) response from server B would just look like a new request. But then this really doesn't work in practice because of firewalls and NAT, for the same reason it's hard to host a game server from behind your firewall, router, and ISP.
If server A receives a UDP packet, can it forward it to server B and have server B directly respond to the end client without going back through server A since UDP is connectionless?
Yes, it can. However, there are a few caveats:
NAT devices, which most client are behind of. There are several types of NAT devices. A full-cone NAT will accept the redirected packet just fine, but an address-restricted NAT would require the packet to return from the same address it was sent to (hence, your anycast idea would work, as well as simply having server B spoof the IP of server A). A port restricted or symmetric NAT would also require the same source port (i.e. server B has to send the response from the same port server A received it from).
Other types of network middleboxes, such as firewalls might block the returning packet
Application - will the client application accept a response from a different IP address and port?
Sorry, my networking skills are subpar,
I have a scenario where I have 2 different networks and have 2 servers in those networks, server A is in network A, server B in network B
When someone tries to connect to an external server (over internet), we have a virtual interface configured between A & B (IPIP tunnel)
1)
If I try to netcat/telnet external server (x.x.100.3), I have a route on serverA that routes to my virtual inteface (tunnel1)
2) tunnel1 sends packets over IPIP tunnel to its peer "tunnel2"
3) I need to route any requests to x.x.100.3 over to another internet-facing p1p1 interface
4) serverB sends packets to external serverC over p1p1 interface (I tested running tcpdump -i p1p1 and can see the packets going out
5) reply from C comes back to p1p1
If I do the same netcat cmd from B, I get connected. Yet from A, I get a timeout.
SO my question is, how do I configure this setup so the user who initiates Netcat on server A, gets the reply from server C? Right now the connection stops at server B (p1p1) because the packet header is changing after the Route on B.
I tried playing with iproute2 table rules but cannot get it to work. I basically need to use Server B as a "proxy" network server for any requests going to external server C.
Thanks!
figured out the problem, I didnt have a gateway route in place. This was preventing the back-forth flow of packets.
heres the write up how to setup IPIP tunnel between 2 networks,
https://sites.google.com/site/mrxpalmeiras/linux/create-ipip-tunnel-between-networks
I'm setting up 4 servers that each have RESTful APIs that go over HTTPS. Because we're in the early stages of a startup, I'm going to host these in my closet.
I have business-class Comcast service, so I can get a static IP address or a series of them. The IP addresses are $10/ea per month, so I can save about $30 if I get just one. I realize this sounds like I'm being super cheap, but we're pinching pennies until we get some customers.
We will probably use one server as a "tools" server that will allow us to reach the other servers via SSH; the other 3 servers will need to have HTTPS open to the internet on the LAN.
I'm considering getting one static IP address, and then using my router to forward HTTPS traffic to the various servers. The port forwarding would look something like:
WAN Port LAN Port Server
22 22 Tools
1443 443 Server 1 (API via SSL)
2443 443 Server 2 (API via SSL)
3443 443 Server 3 (API via SSL)
I would then set up A NAME records in my DNS that would be:
tools.mydomain.com -> <static IP address>:22
server1.mydomain.com -> <static IP address>:1443
server2.mydomain.com -> <static IP address>:2443
server3.mydomain.com -> <static IP address>:3443
Is this a reasonable approach? Will it work?
You cannot direct traffic to a specific TCP port with DNS records. You can only point at an IP-address. The client by default uses tcp port 80 for HTTP and port 443 for HTTPS (unless you explicitly name the port to use in the URL).
Furthermore you cannot have multiple HTTPS-based hosts using the same IP address unless they also use the same SSL certificate. That is because the SSL handshake takes place before the client reveals to the server which hostname it was trying to reach, so the server can only give out an SSL certificate based on the IP address (and port) that was connected to.
In this particular instance, if you have four servers that actually have the same domain, you can get a wildcard SSL certificate (i.e. it covers *.mydomain.com) and then you can actually get away with one single public IP address for all four servers. Just point all DNS records to the same IP address and then you have the server give out your wildcard certificate which is valid regardless of which hostname the client is using. After the SSL handshake is thus completed, the server can look at the Host: -header in the client request to determine which server the request was actually intended for, i.e. you have one server acting as the HTTPS-endpoint where all HTTPS-requests are received and then internally forwarding to unencrypted request to the correct server (or handle all servernames virtually by one physical server).
If you are using Apache HTTP server I suggest you read about name-based virtual hosts and proxy forwarding:
http://httpd.apache.org/docs/current/vhosts/name-based.html
http://httpd.apache.org/docs/current/rewrite/vhosts.html
http://httpd.apache.org/docs/current/rewrite/proxy.html
The scenario is the following. I have two machines A and B:
A: Client (behind NAT)
B: Server (behind NAT)
I want B to be able to listen on any given port, so that A can send packets to B through that specific TCP port and receive any response. If both machines are not behind a NAT it is pretty straight foward process. However how do I make it work so that it works even when B is behind a router, without him having to go change the router configuration enable some port forwarding etc...
For example, how do peer-to-peer programs like torrent clients work without the user having anything to configure?
To answer the example of Peer to Peer programs, and in general: There is a technology called Universal Plug and Play which NAT routers can use to allow clients behind them to expose ports to the outside. That's what bittorrent clients can use so the other clients can directly connect to them.
An alternative to a proxy server is a match-making server. Instead of proxying all of the traffic, the match maker just negotiates until the peers can talk to each other. This involves finding the external public IPs of the peers and talking to each one so that the firewall/router knows that the peers wish to communicate.
This is called hole punching and it often has to be done by the match maker rather than the peers themselves. Once the hole are punched though, the match maker can tell the peers about each other and they can communicate directly.
You will have to either:
Set up port forwarding from the nat
gateway in front the server into the machine your server software is running, and have the client
connect to the IP address of that
gateway.
Create a proxy server sitting
inbetween the 2 nat gatewys so both
your server and client can connect
to that. Both your server and client
have to set up a connection to that
proxy which will mediate the data
between those 2 connections.
Hole punching is moderately well-understood for UDP communication, but it can be reliably used to set up peer-to-peer TCP streams as well. Here is the well detailed article on both TCP and UDP:
http://www.brynosaurus.com/pub/net/p2pnat/