Wednesday, October 25, 2017
I would like to share a short but useful experience that I had a few days ago when I was running a project for a customer. The project consisted of installing and configuring a Synology NAS. The given NAS has some interesting capabilities such a virtualization through a QEMU engine, among others. So, I dedicated a NIC for the NAS's I/O, and the others for the I/O of the VMs. The challenge started when I was configuring the physical NICs for the VMs due to I wanted to configure those just as an ethernet-passthrough, without the presence of IP by the host (NAS). Synology DSM has a straightforward option for disabling IPv6 through the GUI. It is very intuitive, just follow the path "Control Panel -> Network -> Network Interface -> LAN X -> Edit -> IPv6 -> IPv6 setup = Off.", that is it. But, the behavior changes for IPv4. That is to say, when speaking of IPv4 on Synology DSM, it offers only two options through the GUI (getting an IPv4 by DHCP and static assignment). But, I didn’t want to set a static IPv4 address for the dedicated physical NICs for the VMs, nor getting an IP by DHCP. In addition, as expected if a NIC is placed in a VLAN without a DHCP server (DMZ, for instance), the given NIC sets an APIPA address (even when the interface is disconnected).
Refer to the following screen-shoots to get a better idea of it.
Therefore, after some researching without any positive results, I fixed this inconvenient through the following steps (DISCLAIMER: the procedure is NOT described by Synology)
My first attempt was setting up a script to flush any IPv4 address from the VM's dedicated NICs. The script was run during the NAS boot-up process. It worked, but only for a few seconds due to SDM sends a DHCP Discover every 60 secs.
ip addr flush dev ovs_eth1
ip addr flush dev ovs_eth2
ip addr flush dev ovs_eth3
Eventually, I was forced to disabling the DHCLIENT in a abrupt manner. I did it by removing the DHCLIENT “executable”.
cp /usr/sbin/dhclient /usr/sbin/dhclient-COPY && rm /usr/sbin/dhclient
In conclusion, it is working, but if somebody has a suggestion please share to improve it.
Tuesday, August 8, 2017
Also known as an intercepting proxy, inline proxy, or forced proxy, a transparent proxy intercepts normal communications at the network layer without requiring any special client configuration. (Wiki)
There are several options to perform a transparent proxy, being Squid one of the most popular software to implement it. The easiest way to implement a transparent proxy is setting it up as a default gateway. Nevertheless, it is not possible to implement it in a whole scenario. So, The Web Cache Communication Protocol (WCCP) was developed by Cisco Systems and adopted by other vendors. WCCP is one of the best choice to do a transparent proxy, however, it increases the complexity setup at the server side. Therefore, to simplify its implementation, I decided to do it in a different manner by running Route-Maps.
Let’s check the following configuration in order to accomplish this job.
GNS3 (2.0.3) and VMWare WorkStation (12.5.7) as the framework.
Router image. (vios-adventerprisek9-m)
MLS Switch image. (vios_l2-adventerprisek9-m)
PFSense (community 2.3.4)
PC client. (Linux box 3.16.6-tinycore)
The focus of this configuration is the interactivity between PFSense and the MLS Switch.
PFSense was started from a fresh installation. Only one NIC was add, therefore the VLAN sub-interfaces had to be configured. VLAN10 has a subnet 172.16.0.0/27, while VLAN20 has a subnet 172.16.1.0/31. The default route was placed at the VLAN 20, so packets coming from VLAN10 are forwarded through VLAN20. In addition, NAT was completely disabled. Then, Squid and iftop packages were installed. Once Squid was installed and started, some basic changes were necessary to enable the transparent proxy feature.
The next step was configuring the MLS Switch (or router). IP Policy was enabled on the SVI 10, so that the packets that meet the IP policy be forwarded to PFSense, otherwise packets have to continue the established path by the routing table. Below, the router and MLS's configurations to get a better standpoint of the exposed so far
As the screenshots show, once the IP Policy is up, every packet addressed to a L4 port defined on the extended ACL, will be forwarded to the PFSense box in order to be allowed or denied, according the Squid policy already defined. For example, the first screenshot shows that the browser got access to Google. Take a look the certificate is not the Google valid certificate, instead it is a self-signed certicate, but the access was permitted. Then, the next screenshot shows that even when Facebook is carried over SSL, the access was denied.
Then, the boxes show current status of the IP Policy and each one of its elements.
Adding a new statement that include ICMP protocol on the top of the Route-Map ACL, and launching a traceroute from the client host, can gives a step by step of how the packets are been carried. Also, iftop be launched in the PFSense box to displays the packets incoming and outgoing on each VLAN subinterface.
As we can see, it is an option when a transparent-proxy needs to be run. It does not need any configuration at the client side. Also if the transparent-proxy stops, the clients still reach their destination, and the most important is, HTTP/HTTPS policies can be applied.
Saturday, June 10, 2017
Monday, January 30, 2017
192.168.11.1/24 - - > Windows computers
192.168.11.11/24 - - > Linux box
192.168.11.111/24 - - > Apple computer
By the way, the switch has not a IP address assigned, because it is not required. The Windows computer has Windows Firewall disabled, and the service of File and Printer Sharing (SMB) enabled. The Linux box is publishing three folders by running python -m SimpleHTTPServer TCP-PORT. The web publishing service is assigning an unique TCP port to each folder, from 10001 to 10003. The OS-X computer manages the switch through a serial port, sends some pings to Windows (192.168.11.1) and the Linux box (192.168.11.11), displays the content of each web folder (Text01, Text02...) and connects to the Windows computer through SMB. Everything happens as expected, everything is normal, nothing fancy. The interesting thing starts once the VACL commands are introduced to the switch. As you can noticed in the video below, the Windows computer continues working normally. That is to say, Windows continues answering PING and sharing folders. The lab has been focused on the Linux box. So, after introducing the VACLs commands in the switch, the Linux box stopped answering PING, also the administrator has decided to disable the TCP port 10003 to be reachable by the hosts in the same VLAN. Let's watch a video to get a visual idea, step by step of the described topology.
192.168.100.11/24 and 192.168.200.11/24 - - > Apple computer
192.168.100.12/24 and 192.168.200.12/24 - - > Linux box As the coming video shows, each computer can PING request and reply without any problem. But, as soon the VACL commands are deployed in the Switch, the normal development changes, and the addresses corresponding to the network 192.168.200.0/24 are sudenly stopped.