I am trying to configure l3ACL application for gateway.l3fwd ACL Dpdk application is running in Mellanox NIC.using dpdk (dpdk-stable-20.11) as a shared library.
Edit:
Earlier scenario of Connection setup of l3fwd acl testing using Trex Traffic generator
enter image description here
In this scenario the packets are forwarded by the L3fwd ACL application of DPDK in the direction from Port 1 to Port 0 of the Trex traffic generator. This was made possible by including the MAC address in the --eth-dest flag with the MAC address indicated by the Trex at initialization. On including this MAC address the packets were detected by the Rx side of the traffic generator i.e Port 0.
Current scenario
This setup was modified to mimic gateway level deployment to test L3fwd ACL as shown in the connection diagram attached below.
Connection Diagram attached
enter image description here
In this setup the ports connected to the traffic generator are replaced by two machines that mimic the external network and internal LAN network as shown. We have tried to ping the external and internal network without running DPDK application. The ping in the network is working without enabling DPDK. The L3fwd ACL application was subsequently started with the command given below with the physical MAC address of the machine which was replaced at the port 0 side which was earlier connected to the traffic generator. Port 0 received the traffic from the L3fwd ACL application in the case of the traffic generator. The main difference is that we are including a physical MAC address with the --eth-dest flag in the gateway scenario whereas an emulated MAC indicated by the traffic generator was used with --eth-dest flag to forward the packets in the working setup for L3fwd ACL using traffic generator in a loopback manner.
The physical MAC address of the interface of the Rx side of external network machine connected at Port 0 is not receiving the traffic destined out from the L3fwd ACL application. The configured Route entry in rule_ipv4.db is R0.0.0.0/0 0.0.0.0/0 0 : 65535 0 : 65535 0/0xff 0.
Not able to trace the packet at the interface with Mac address given in –eth_dest parameter.After starting l3fwd acl destination host is unreachable.
Command used for L3FWD ACL
./dpdk-l3fwd-acl –l 1-7 –n 4 -- -p 0x3
--config=”(0,0,1),(1,0,2),(0,1,3),(1,1,4),(0,2,5),(1,2,6),(0,3,7)” --rule_ipv4=”/root/rule_ipv4.db” –rule_ipv6=”/root/rule_ipv6.db” –eth-dest=0,next-hop-MAC-here
How to configure the l3ACl dpdk sample application for gateway?
DPDK example code l3fwd-acl works on IP packets only. For non-ip it is dropped in the function process_one_packet. While using external packet generator like TREX, DPDK_PKTGEN, SCAPY, PACKETH, PCAP replay with IP packets are not dropped and ACL lookup is performed. Packets matching with the condition are forwarded through DPDK ports while no match are dropped.
In your current scenario, connecting to the interface to actual network could lead to
ARP or RARP packets to be generated
LDAP packets to be generated
If connected over managed switch VLAN packets are generated.
In all above cases these are treated as non-IP packets leading to drop of the same. Hence the recommended way is to use by adding static ARP entry to end machines or switch. This will eliminate the ARP and RARP packets.
Note: If the external devices are not configured with promiscious mode, please use --eth-macaddress to help l3fwd-acl to update the MAC address too.
Related
I have generated traffic via pktgen dpdk on one VM and L2fwd on another VM. Two ports which are virtio-net are attached via internal network. I wanted to confirm If I am getting right results for L2 forwarding being done when traffic is generated.L2fwd result 1 L2fwd result 2 L2fwd result 3
since virtual box is used on host linux machine, the configuration need to be correct in network settings to allows packet flow from host to guest. By changing host only mode in the adapter settings one can send packet to and fro from the desired NIC.
I'm trying to get TCP timestamp from the packets for clock skewing purposes on my application which is hosted on EC2. In my network I have an ALB.
So my question is how do I get TCP level packet information in my app ? Since ALB filters out all the OSI Layers except application level (HTTP)
If the only reason to get access to TCP packet is to detect timestamp and correct clock drift, I would suggest to configure your EC2 instance to use NTP time server instead.
https://aws.amazon.com/blogs/aws/keeping-time-with-amazon-time-sync-service/
That being said, the ALB is not "removing" TCP information from network packets. HTTP connections made to your application are still transported over IP and TCP. If you need low level access to network packets from an app, I would suggest to look at the pCAP library which is used by TCPDUMP and many other tool to capture network traffic on an interface.
https://www.tcpdump.org/
[UPDATED to include comments]
It is important to understand the TCP connection between your client and the ALB is terminated at the ALB level. The ALB creates a second TCP connection to forward HTTP requests to your EC2 instance. The ALB does not remove information from TCP/IP, it just creates a second, independent and new connection. Usually the only information you want to propagate from the initial TCP connection is the source IP address. The ALB, like most load balancers and proxies, captures this information from the original connection (the one received from the client) and embed the information in an HTTP header called X-Forwarded-For.
This is documented at https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html
If you want to capture other information from the original connection, I am afraid it will not be possible using ALB. (but I also would be very curious about the use case, i.e. WHAT you're trying to achieve)
I am trying to understand how AWS NLB routes traffic between a client and targets. I ran a simple test with NLB using tcpdump in both the client and server to see who is sending packets where etc. This is what i found from tcpdump -
NLB IP:172.31.29.2 Mac:02:4d:8f:d9:22:e2
Client IP:172.31.20.174 Mac: 02:7e:b1:06:aa:42
02:7e:b1:06:aa:42 > 02:4d:8f:d9:22:e2, ethertype IPv4 (0x0800), length 74: 172.31.20.174.47682 > 172.31.29.2.80: Flags [S]
02:4d:8f:d9:22:e2 > 02:7e:b1:06:aa:42, ethertype IPv4 (0x0800), length 74: 172.31.29.2.80 > 172.31.20.174.47682: Flags [S.]
Server IP:172.31.24.59 Mac: 02:0d:2c:74:be
02:4d:8f:d9:22:e2 > 02:0d:2c:74:be:88, ethertype IPv4 (0x0800), length 74: 172.31.20.174.47682 > 172.31.24.59.http: Flags [S]
02:0d:2c:74:be:88 > 02:7e:b1:06:aa:42, ethertype IPv4 (0x0800), length 74: 172.31.24.59.http > 172.31.20.174.47682: Flags [S.]
From #4 line above, server responded with an acknowledgement packet directly to the client - which makes me think that it is doing Direct Routing instead of sending response packets via the NLB.
But, when i look at line #2, i expected to see that the acknowledgement packet from the server IP/Mac address instead of the NLB IP/Mac address as seen in line #4. I do understand that in line #3, the mac address is of NLB but since NLB preserves client IP, we can see the client IP intact.
Would appreciate if some can explain how this routing is happening.
The short version: Network Load Balancer isn't really a device, and VPC isn't really Ethernet, and what you see is an artifact of this otherwise-convincing illusion.
NLB is provided by an internal service called AWS Hyperplane, which is integrated with the VPC network infrastructure. It manipulates traffic in the network at the flow level, rewriting source or destination IP addresses as the traffic passes from machine to machine.
Take two machines on the same subnet, without an NLB in the mix, and who don't have each other in their ARP tables... and ping from one to the other. On the instance where you run the ping, you'll see ARP traffic going out to discover the other instance, and you'll see the ARP response come back from the other instance. But on the other instance, you'll sniff... nothing, because that ARP negotiation never actually occurred end-to-end. It only looks like it does. The ARP response is forged by the network, including the source MAC address of the second machine.
Something similar is happening here. The network is essentially forging the source MAC at the same time it rewrites the source IP... so the server responds "directly" to the client IP, but then the network translates both the source address and the source MAC to appear to be "from" the NLB ENI. It gives the impression of asymmetry but that's an illusion, because the traffic isn't really going "through" the NLB in either direction.
I am currently attempting to configure iptables to only allow certain mac addresses to connect to port: 3690 (svn).
Step 1 - On EC2 Management Console > Security Groups (group name: default) I opened port: 3690 for all subnet.
Step 2 - On my linux server (Amazon Linux AMI 64-bit), I configured iptables:
2.1 Allow my mac address (port 3690)
2.2 Drop from all (port 3690)
[ec2-user#ip-172-31-7-2 ~]$ sudo iptables -n -L -v --line-numbers
Chain INPUT (policy ACCEPT 1974 packets, 206K bytes)
num pkts bytes target prot opt in out source destination
1 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3690 MAC 50:46:5D:C7:63:C1
2 5 272 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3690
But the firewall cannot work correctly. I cannot telnet port 3690 from the mac address. If I delete the iptables, all client can access this port.
Could anyone help me???
If the client and the server are not on the same IP subnet, then by definition there must be at least one router between them, so again by definition the two systems are not going to be able to detect each other's MAC address.
MAC addresses identify devices at layer 2 on their local, physical network only... while routers operate at layer 3, stripping off the incoming layer 2 address and using their own layer 2 address when sending the packet to the next router or host on the way to the destination. An incoming packet from a device on a different subnet always arrives with the MAC address of the router that delivers the packet.
What you are trying to do is not possible for machines on different subnets, and it's just as well, because MAC addresses are absolutely trivial to "spoof," making MAC address-based security nothing more than security by obscurity, which is not a meaningful level of security.
You should probably not even consider running svnserve listening on an Internet-connected machine like this. The svn+ssh:// mechanism supported by subversion does not require the server to have an always-open port listening for connections... it works with your existing ssh keys, which, assuming you haven't careleslly configured sshd to allow logins with only a password (instead of keys) are a phenomenally more secure mechanism for controlling access, not to mention automatically encrypting your traffic as it traverses the Internet.
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth
Although Michael's answer is great, I would like to add a 'practical' solution.
Dome9 can automate your Firewalls and allow on-demand access to your server while 'cloaking' it from the rest of the internet. It can do so by dynamically managing your AWS security groups or by managing your iptables.
Disclaimer - I'm a proud Dome9er ;)
I have a NAT configured to run when loading up my favorite Linux distribution in VitualBox. This allows outgoing connections to work successfully.
How do I allow incoming connections to this box, like, say, Web traffic? The IP address is 10.0.2.15. A ping request from my main box results in a Timeout.
VirtualBox (after version 1.3.8, anyway) will let you map incoming connections in the NAT configuration. There's an excellent tutorial on Aviran's Place that describes the steps to configure port mapping.