I have several lines and I wonder if some are shadowed due to this?
IP, TCP, UDP, ICMP, GRE, IGRP all use IP at the Network Layer. The IP statement does include all layer 3 protocols.
You should be careful while defining access lists.
Choosing ip will cover both tcp and udp so to prevent shadowing, you should order the ACL carefully, not put the ip ACL on top.
yes, but it doesnt include protocols like gre etc, if you need vpn tunnels or something similar
Related
I'm developing a proof-of-concept of some kind of transparent proxy on Linux.
Transparent proxy intercepts TCP traffic and forwards it to backend.
I use https://www.kernel.org/doc/Documentation/networking/tproxy.txt and spoofing sockets for outgoing TCP connection.
On my dev PC I was able to emulate network using Docker and all works fine.
But I need to deploy test environment on AWS.
Proposed design:
Three VMs within the same subnet:
client, 192.168.0.2
proxy, 192.168.0.3
backend, 192.168.0.4
On client I add route to 192.168.0.4 thru 192.168.0.3
On proxy I confugure TPROXY to intercept TCP packets and forward it to backend with 192.168.0.2 IP source address. Here our transparent proxy works.
On backend I run simple web server. Also I add route to 192.168.0.2 thru 192.168.0.3 otherwise packets will go back directly to 192.168.0.2
The question:
Will proposed network design work as expected?
AWS uses some kind of software defined network and I don't know will it work in the same way as I would connect 3 Linux boxes to one Ethernet switch.
Will proposed network design work as expected?
Highly unlikely.
The IP network in VPC that instances can access is, from all appearances, an IP network (Layer 3), not an Ethernet network (Layer 2), even though it's presented to the instances as though it were Ethernet.
The from/to address that is "interesting" to an Ethernet switch is the MAC address. The from/to address of interest to the EC2 network is the IP address. If you tweak your instance's IP stacks by spoofing the addresses and manipulating the route tables, the only two possible outcomes should be one of these: the packets will actually arrive at the correct instance according to the infrastructure's knowledge of where that IP address should exist... or the packets will be dropped by the network. Most likely, the latter.
There is an IP Source/Destination Check Flag on each EC2 instance that disables some of the network's built-in blocking of packets the network would otherwise have considered spoofed, but this should only apply to traffic with IP addresses outside the VPC supernet CIDR block -- the IP address of each instance is known to the infrastructure and not subject to the kind of tweaking you're contemplating.
You could conceivably build tunnels among the instances using the Generic Route Encapsulation (GRE) protocol, or OpenVPN, or some other tunneling solution, and then the instances would have additional network interfaces in different IP subnets where they could directly exchange traffic using a different subnet and rules they make up, since the network wouldn't see the addresses on the packets encapsulated in the tunnels, and wouldn't impose any restrictions on the inner payload.
Possibly related: In a certain cloud provider other than AWS, a provider with a network design that is far less sensible than VPC, I use inter-instance tunnels (built with OpenVPN) to build my own virtual private subnets that make more sense than what that other cloud provider offers, so I would say this is potentially a perfectly viable alternative -- the increased latency of my solution is sub-millisecond.
But this all assumes that you have a valid reason for choosing a solution involving packet mangling. There should be a better, more inside-the-box way of solving the exact problem you are trying to solve.
I have a VPS on which eth0 is configured , i want to configure a interface eth0.1 but i want to know if i will configure this new interface the data flow will be divided between eth0 and eth0.1 ?
I want to use eth0 Ip address for all the data flow on server like custom written scripts and eth0.1 Ip address to access it from browser as i have web-server on it.
Linux, by default, will send all packets out the default interface for the subnet, which is most likely eth0.
iproute2 attempts to solve this problem by redirecting packets out on the same interface on which they have been received.
http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2
So, to answer your question, most packets on your system will probably already go out eth0 (assuming it's the same subnet).
If you set up an alias interface, eth0.1 (from your example), any programs listening on either all interfaces, or specifically, to eth0.1 will be able to receive packets on that IP address.
To add a secondary IP address you use the : separator on the interface name. Suppose you have eth0 assigned with 11.22.33.44 and you also want it to work with 11.22.33.55. Then you would just do:
ifconfig eth0:1 11.22.33.55
If you don't touch routing through the ip route command, 11.22.33.55 won't ever be used as an outbound interface, unless you're answering a request that points to 11.22.33.55 itself, so there are two more things to do.
The first is setting up your webserver's listening address to 11.22.33.55 instead of 'any' IP or 11.22.33.44. This depends on your webserver, in the case of apache check out the Listen directive.
The second thing, if you use a domain, to do is setting up a DNS record to point to 11.22.33.55 instead of 11.22.33.44. Take care because a domain name can't be resolved to a different address depending on the destination port, so you'll need a domain name for each interface. The alternative is directly using the IP address 11.22.33.44 for the script stuff and using the domain name for the webserver only.
After you've done this you can safely use tcpdump, iptables & friends on both the physical and the virtual interface.
I'm not quite sure how the firewall can tell what transportation is being passed - TCP\UDP?
also - when I have statefull VS stateless FW - I know that there is the difference when using TCP, but what about UDP?
thanks alot! :)
Have a look at https://en.wikipedia.org/wiki/IPv4#Header and see the Protocol field.
The header of the packets are completely different, TCP is much bigger for example. A stateful firewall needs to intercept the TCP headers to map the packets to its state table, but also stateless firewalls sometimes have techniques implemented to recognize valid TCP or UDP headers. Most home routers (broadband/wireless) make use of this when you are using port forwarding to distinguish between both protocol versions.
I'm trying to test a ethernet bridging device. I have multiple ethernet ports on a linux box. I would like to send packets out one interface, say eth0 with IP 192.168.1.1, to another interface, say eth1 with IP 192.168.1.2, on the same subnet.
I realize that normally you don't configure two interfaces on the same subnet, and if you do the kernel routes directly to each interface, rather than over the wire. How can I override this behavior, so that traffic to 192.168.1.2 goes out the 192.168.1.1 interface, and visa-versa?
Thanks in advance!
This is a guess, but I hope it is in the right direction.
Make more-specific routing table entries, along the lines of:
route add -host 192.168.1.2 dev eth0
route add -host 192.168.1.1 dev eth1
You may also need to fiddle with the accept_local configuration for both interfaces -- or the all setting. (Turning this on may make your machine more susceptible to IP source spoofing attacks; be sure you have good ingress firewall rules elsewhere to prevent trouble.) (See sysctl -a | grep accept_local for what I'm talking about.)
I think you need something like Mac-Vlan in your Linux. This cannot be done with NAT only. Read this: http://www.linuxjournal.com/article/7268.
When maintaining networks, it is often an expedient thing to do to run a transparent proxy. By transparent proxy I mean a proxy that 'hijacks' outgoing connections and runs them through a local service. Specifically I run a linux firewall with squid configured so that all tcp/ip connections fowarded on port 80 are proxied by squid.
This is achived using the iptables 'nat' table, using IPv4.
But iptables for IPv6 does not have a 'nat' table, so I cannot use the same implementation. What is a technique I can use to transparently proxy traffic for IPv6 connections?
A viable way to do this is with the TPROXY rule in iptables, documentation is available here:
http://wiki.squid-cache.org/Features/Tproxy4#IPv6_Support
http://www.mjmwired.net/kernel/Documentation/networking/tproxy.txt
This should be supported Squid (>= version 3.2). Using --enable-linux-netfilter and the iptables -t mangle -j TPROXY rule.
iptables has a QUEUE target, which you can use to deliver packets to userspace. I am not sure, but perhaps something could be implemented there.
Past that, you could take a stab at adding something to the kernel to do redirection.
You can't. Quoting from squid-cache.org:
NAT simply does not exist in IPv6. By
Design.
Given that transparency/interception
is actually a feature gained by
secretly twisting NAT routes inside
out and back on themselves. It's quite
logical that a protocol without NAT
cannot do transparency and
interception that way.
Here's an implementation:
http://www.suse.de/~krahmer/ip6nat/
Another sort of ugly hack:
MARK all traffic with iptables (seems, there is CONNMARK target for IPv6)
route all marked traffic to tun device
do user-space NAT in the daemon listening at tun device
...
Write your own implementation of NAT in IPv6 stack.