I need to set up a solution which is for routing specific TCP/UDP packets between the devices in two separate VLANs through a proxy server. For eg: all my computers are connected to one VLAN(1) and my printers are one another VLAN(2). I can reroute all the packets from VLAN(1) to VLAN(2). My objective is to only reroute packets which generated for printers in VLAN (2) from computers in VLAN (1).
Is there any way in Layer 3 routing for achieving this?
Normal routing is based on the destination IP address. If you need to select routes based on source IP address or source/destination port numbers you require policy-based routing.
What you're describing though is simple, destination-based routing. Just add a route to VLAN 2 on your default gateway (or connect it directly) and you're set. (Obviously, the printers in VLAN 2 need to have a route back as well.)
If you want to limit the routed protocols to the printing specific ones or filter by source address you need to use a firewall or switch/router ACLs.
Related
Good day
Do you have any idea how to find WIFI routers or devices which is connected to specific LAN sockets in network?
I am try find this devices from logs Elasticsearch + Kibana namely
https://www.elastic.co/guide/en/beats/packetbeat/current/configuration-interfaces.html
With this solution I have problem with set up : packetsbeats.
Other solution which I found is : WireShark or Advanced IP Scanner or Angry IP.
With this solution /tools is problem with default setting of routers / devices which is lock ports. Its mean I can get all IPs or MACs in network but how I will get know which is IPs or MACs belonging to Routers / NTB / Mobiles ect..?
From this reason I decide find routers in network from logs by Kibana.
Do have any idea or did you make something like me?
Thanks
Wi-Fi (IEEE 802.11) is a layer-1/2 protocol, but routing is a layer-3 function, so there really is no such thing as a Wi-Fi router. There are some routers that have Wi-Fi interfaces, but they are routing a layer-3 protocol, e.g. IPv4, not Wi-Fi. Ports are layer-4 addresses for some layer-4 protocols, e.g. UDP, and they have nothing to do with routing layer-3 packets.
A router is simply a host on a layer-2 LAN. The configured gateway for your host is usually a router. The gateway is the host on a LAN to which your host sends packets destined to a different network.
Determining which hosts on a LAN are routers is a problem because you have no way to know which hosts are actually routers. You can have multiple routers on a LAN, but your host will be configured with one as its default gateway.
If you want to determine which host is the gateway for your host, then you should look at the configuration of your host, not at any particular host on the LAN.
I have a ruby server based on TCPSocket (non-HTTP).
I have 2 different domains, both pointing with an A-Record to my servers IP Address (the same one). So, there are clients connecting to one of those domains.
Is it possible to tell which domain a client was connecting to?
I saw that this is possible in other protocols, but I'm not sure if this is based on manually added headers or really extracted from the basic tcp/ip connection. E.g. in PHP there is $_SERVER["HTTP_HOST"] which shows to which domain a client was connecting.
At the TCP socket level, the only things that are known are the source and destination IP addresses (and ports) of the connection. How the IP address was resolved via DNS is not possible to know at this layer. Even though HTTP works on top of TCP, HTTP servers have to look at the HTTP headers from the client to know which domain they are making a request to. (That's how the HTTP_HOST value gets filled in.)
One possible solution is to configure your server to have an additional IP address. This can be by assigning an additional IP address to the NIC or adding an additional NIC. Then have each domain use a different IP address. Otherwise, this is not possible and you may want to consider your application protocol on top of TCP to convey this information.
I'm trying to open multiple sockets in a ruby application on different network interfaces in linux. For example lets say I have the interface eth0 with an IP of 192.168.1.2 and the interface wlan0 with the IP address 10.0.0.2. I would like to simultaneously connect to a server with a socket on each interface. I thought that binding to the IP address of these interfaces would work however that doesn't seem to be the case. In wireshark when I bind to the IP of wlan0 I successfully see the SYN packets send with the correct source IP, but wireshark sees them on eth0 and the socket is never opened.
Ruby version: ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
Here is my current code. I have also tried the Addrinfo method documented on the ruby-doc page for Socket with the same results.
require 'socket'
ip = "192.168.1.2" # IP of internal interface
port = 8000
server = "" # IP of the server I'm trying to connect to goes here
lhost = Socket.pack_sockaddr_in(0, ip)
rhost = Socket.pack_sockaddr_in(port, server)
socket = Socket.new(Socket::AF_INET, Socket::SOCK_STREAM, 0)
socket.bind(lhost)
socket.connect(rhost)
Thank you for any help!
The solution is source based routing
I was able to figure it out, and thought I should leave my answer in case anyone else gets stuck with this problem down the road.
What I needed to do was source based routing. The general idea is to create two routing tables, one that forces traffic on one interface and one that forces traffic on the other, and have an ip rule that uses the appropriate routing table based on the source IP address. I set it up like this:
Creating the tables
First I had to edit /etc/iproute2/rt_tables to add the following lines:
128 multiplex0
129 multiplex1
This created two routing tables with IDs 128 and 129 called multiplex0 and multiplex1.
Adding routes to tables
Next I created rules for these tables as follows:
ip route add default via 10.0.2.2 table multiplex0
ip route add default via 192.168.1.1 table multiplex1
These commands specify the default gateways to use in the routing tables. My 10.0/16 network had a default gateway of 10.0.2.2 and my 192.168.1/24 network had a default gateway of 192.168.1.1.
What if the two networks had the same default gateway?
I believe you can add dev eth0 (or whatever your interface is) to the above commands to specify an interface if your networks have the same default gateway, though I have not yet tested this. I will make an edit when I learn more.
EDIT: I have tested this and it does indeed work. Both routes can have the same default gateway if you specify the interface in the route.
Source based rules
Next I needed to create rules to use these tables:
ip rule add from 10.0.0.0/16 table multiplex0
ip rule add from 192.168.1.1/24 table multiplex1
These rules say that any packet with a source IP in the 10.0/16 range should route based on the rules in multiplex0, while any packet with a source IP in the 192.168.1/24 range should use multiplex1. When the packets use these tables they are directed to the appropriate gateway and corresponding interface. Viola!
EDIT: It would be more accurate to specify just the IP of the network interface in this step! If both interfaces are on a 192.168.1/24 network for example, it would be necessary.
Flushing the cache
Lastly I issued ip route flush cache to make everything take effect and using the ruby code above I was able to open my two sockets on the correct interfaces to the same publicly route-able host.
If I have a UDP server repeatedly receiving requests from the same client machine, when might the client's incoming IP address change even though the user is actually still on the same machine and has not done anything deliberate to change her IP address?
I can think of two cases: (1) packets are coming in via proxy servers that use a pool of different IP addresses, and (2) the client machine is using a dynamically assigned IP address that has expired and been reassigned to a new IP address.
Are there any other cases?
Is it a mobile client? If so, it could change networks. For example -
A phone switching b/w 3G and wi-fi
A laptop changes wi-fi networks (this is infrequent though)
Summary: I'm trying to create sockets to pass data between two physical interfaces that exist on the same machine, and Win32 sockets always forwards the traffic directly in the kernel instead of pushing through the physical interfaces. Is there any way to disable this behavior, perhaps through device settings, registry tweaks, routing table shenanigans, or socket options? We're using Windows XP SP3.
Some background. I'm attempting to build some completely automated IP tests to exercise our custom IPv4 equipment. We have a large lab of Windows XP machines, and individual physical ethernet interfaces for each device we're connecting to. Our devices are effectively ethernet routers each with their own IPs.
We need to send data out our lab machines, through our devices, then back into the same computer. We will be sending Unicast and Multicast UDP, TCP, and broadcast IP traffic through the devices.
We want (and likely need) the traffic to originate on the same machine it is destined to.
To do this, we configure two separate NICs each with their own IP on their own subnet, for instance NIC #1 with 10.0.0.1/24 and NIC #2 with 10.0.1.1/24. Our devices then act like simple passthrough routers, and have two interfaces, one on the 10.0.0.0/24 subnet, one on the 10.0.1.0/24 subnet, which they just forward packets back and forth from.
To generate our data, we'd like to be able to use Win32 sockets, since it is well-understood, well-supported, what our customers are using, and would probably be the most rapid approach. Packet injection is probably feasible for UDP and broadcast IP, but very likely not so for TCP. I'd entertain ideas that used packet injection, but would strongly prefer standard Win32 sockets.
As stated in the summary, the packets never leave the machine. I've googled like a madman and I've not found much. Any ideas?
Use Windows' command-line ROUTE utility. You can configure it so any IP packet sent to a specific IP address on a specific Subnet gets sent to another IP/device. For example:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_2> METRIC 1
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> <DEVICE_IP_CONNECTED_TO_NIC_1> METRIC 1
Alternatively, if you know the index numbers of the NIC interfaces, you can specify them instead:
route ADD <NIC_1_IP> MASK <NIC_1_SUBNET> METRIC 1 IF <NIC_2_INTF>
route ADD <NIC_2_IP> MASK <NIC_2_SUBNET> METRIC 1 IF <NIC_1_INTF>
This way, whenever a packet is sent to NIC #1's IP, the packet goes to the device connected to NIC #2, which will then pass it on to NIC #1. And vice versa for packets sent to NIC #2's IP.
For instance, this is a useful technique for allowing WireShark to capture local IP traffic if the PC is connected to a network with a router. Packets from one local IP/Port to another local IP/Port can be bounced off the router back to the PC so they travel through physical interfaces that WireShark can monitor (WireShark will see duplicate copies of each local packet - one outbound and one inbound - but you can filter out the duplicates).
Winsock is always going to bring the packet data up into the kernel space and deal with it there. Thats the whole point to a generic API is that any device is dealt with at the same "layer". If you want to stick with Winsock, I don't believe you can (or would want to) work around this behavior.
You can remove some of the buffer copying with TransmitPackets or TransmitFile, but not between two device interfaces.
That being said, are you having a performance issue with the additional buffer coping that Winsock performs? Security concerns?
How about running the endpoints of your tester inside of distinct virtual machines? Then you need only a single piece of hardware, but you'll have separate TCP/IP stacks that don't know each other are local (and most VM solutions pass the packet straight through the host unchanged, I don't think the host is going to grab the packet and send it straight to another VM unless you configure bridging between VMs... but you'll bind each VM to a different physical network adapter).