• Easy Remote Client VPN Solution with a Cisco ASA

    I’ve posted an article on Client VPN setup using OpenVPN and I noticed I didn’t have one regarding Cisco ASA. A Cisco ASA being a very common Security Appliance used by small and large companies. This article will cover how to setup a standard remote client VPN utilizing IPsec as the crypto carrier. Cisco also has their own proprietary remote client VPN solution called AnyConnect. I will be posting an article after this one on how to set an AnyConnect solution up and include what the differences are between it and the standard IPsec remote client VPN contained in this article.

    A remote client VPN is something very common in workplace now-a-days. It allows users to appear as if they are on the company’s internal network over an insecure medium(e.g. Internet, untrused Network, etc). It does so by using IPsec. IPsec is a tried and true Layer 3 securing technique that requires both parties involved to mutually authenticate each other before passing traffic.

    A few things to keep in mind regarding remote client VPNs.

    • First, a subnet is required for client’s to be put on when successfully authenticated and authorized via the remote client VPN. This can be the same subnet as one already existing on your network or a separate one with a firewall in-between The later being best in practice and security.
    • Secondly, deciding on split-tunneling vs all-tunneling. The difference being on the client would you like all traffic to be forced across the tunnel or allow clients to communicate with both their local network and the networks on the otherside of the VPN. For best practice and security, all-tunneling is recommended.
    • Third, Access Lists and tunneled networks. Here we will decided what Remote VPN users will have access to other networks. We will also, in the case of split-tunneling, create an access-list of what networks to tunnel for the Remote VPN user.
    • Fourth, provisioning standard network services for VPN user’s. Remote VPN user’s will need a default gateway, DNS servers, domain suffix, an address pool, proxy settings, etc.

    [Read More…]

  • Transparent SSL Web Proxy redirection using WCCP, Cisco ASA, and Squid 3.4+ with Wireshark Captures

    I’ve posted a few articles on how to set up a Forwarding Proxy using Squid, and using benefits like caching and content blocking (Ads, adult, gambling, etc). This can bring centralized web security and delivery to you and your users.  However, users need to be expliclty configured to use the Proxy service. This means having their web browser like Firefox or even Internet Explorer set with the DNS or IP address of the Proxy server. This can be an issue if youhave little or no management of the user’s Web Browsers configuration.  This is where a content-routing protocol like WCCP(Web Cache Communication Protocol) comes into play. With WCCP we can influence specific user traffic to be encapsulated and re-routed to your Proxy server. The difference between this and some of the other ways to force web traffic to your Proxy server(like iptables redirection) is the original Web packet generated by the user’s device is not altered. Instead it is encapsulated when it reaches your WCCP receiver running on an upstream egress router(user gateway towards Internet). It is then re-routed via this encapsulation to your Proxy server which is WCCP aware.

    Before we begin, you will need a few things:

    • Squid Proxy Server 3.4+ compiled with WCCP
    • Router or Security device capable of running the WCCPv2 service(See vendor list here…)
    • Some knowledge of Web Proxy Technology.
    • A Web Browser to test with.
    • Your favorite beverage and some patients.

    Topology

    Notice: Cisco ASA only supports having the user subnet(s) and the cache-engine(Squid Proxy server) behind the same Cisco ASA interface(inside,dmz,outside,etc). The reason for this is the WCCP processing on the ASA happens after interface ACL, meaning for example ACL on your inside interface are processed before any WCCP manipulation can begin.

    wccp flow

    1. User requests a web resource on outside interface(usually the Internet) of Router/Firewall.
    2. WCCP Server (Router/Firewall) catches this interesting traffic(traffic we want to redirect) and encapsulates it within a GRE tunnel to the WCCP Client(Squid Proxy Server) on the other end of the tunnel.
    3. WCCP Client (Squid Proxy Server) decapsulates the GRE payload and fetches the original client request just like an ordinary Web Proxy would.
    4. WCCP Client receives a response from the external web server.
    5. WCCP Client (Squid Proxy Server) serves the web page back to the original User by spoofing the source IP address(This is key). Spoofing is done by rewriting the source IP address field of the packet with the External Resource’s IP address. This makes it look like the packet the user receives is from the external web site.

    [Read More…]

  • Link Aggregation with LACP and NIC Teaming

    Hi All!, been awhile since I posted an article and I don’t think I have ever posted one on Network Link Aggregation!! Link Aggregation is the physical combining of network links into one logical link. There are two main advantages to this practice. First is the increase throughput that you obtain by combining links, for example combining 2x 1GB links will increase your total bandwidth to 2GB.(Keep in mind this will not change your latency…) Secondly, link aggregation grants the benefits of redundancy. Imagine the setup above. If 1 of the 1GB links fails, you would still have the other 1GB link to fall back on, woot!.

    Wikipedia Image
    –Image From Wikipedia
    [Read More…]

  • Network Traffic Monitoring — nTop vs darkstat

    Hey All, so I posted an article on setting up your own Linux based firewall using iptables, and thought it would be nice to be able to monitor the connections coming in and out of each interface on the Linux Firewall. So I installed and played with two passive Network Traffic Monitoring applications; nTop and darkstat.
    [Read More…]

  • NAT, Dynamic NAT, NAT Overloading/Masquerade with IPTables

    If you have had experience with NATs via Cisco Routers or read about them in your CCNA studies, there are 3 Network Address Translation(NAT) types. Technically, two, see here, plus a third special case.

    • Static NAT, one-to-one mapping
    • Dynamic NAT, pool-to-pool mapping
    • Dynamic NAT with PAT Overload, many-to-one mapping

    So as you can see the two types are static NAT and Dynamic NAT, with the special case of Dynamic NAT with PAT overload.

    [Read More…]

  • Network Adblocking using Squid, SquidGuard, and IPtables

    I originally discovered Adblock Plus when I first downloaded Firefox many years ago. Since then I’ve installed the Adblock plugin right after Firefox, etc. It’s become so standard that I almost think Firefox should just bundle them together. Including it in it’s default install exe.

    Adblock Plus works as if it were a local content policy,  filtering each request you make with Firefox. Each URL, each domain, each link you navigate to is check based on a static blacklist of expressions and URLs. If a match is found, Adblock Plus simply discards the content from rendering. The discarding and allowing content to load is managed by the Content Policy engine within Firefox. Adblock Plus simply utilizes this in order to block the unwanted contents. Or at least this is my comprehension of how it works. :-p

    Setting up your own Network wide Adblocker

    The purpose of this guide and tutorial is to instruct you on how to set up your own network based adblocker. Expections after completion is every client browser on the network will benefit from adblocking. I will include as much as possible, and feel free to ping me with questions or comment down below.

    You will need:

    1. Computer that will be running the Web Proxy. (For this article, see specs below)
    2. OS that will host the Proxy Software. (For this article, Ubuntu 12.04 32-bit Server)
    3. Proxy software that allows rewrite engines/programs. (squidGuard)
    4. Content-Control-Software or URL Redirect Application(This will consume your blacklists)
    5. URL and RegExp Blacklists consumable by your Content-Control-Software (Here are some free ones)
    6. Optional: ipTables for transparent proxy redirection
    7. Patients and enthusiasm :-p

    [Read More…]

  • What is BIGIP F5 (LTM and GTM)?

    I’ve worked with BIGIP F5 hardware for over two years now, and have become quite familiar with the great features it provides. For those who are unfamiliar with BIGIP F5 hardware, it is network hardware company specializing in load balancing at both the local and global layers of an enterprises network infrastructure. Their website is located here.

    BIGIP F5 product family consists of many different components, however the two major ones most network engineers are familiar with are the Local Traffic Manager(LTM) and the Global Traffic Manager(GTM). Both are network rackable load balancers.

    The GTM

    is used as an “Intelligent DNS” server, handling DNS resolutions based on intelligent monitors and F5’s own iQuery protocol used to communicate with other BIGIP F5 devices. Seen at the top level of a data center, especially in multiple data center infrastructures, deciding where to resolve requesting traffic to. The GTM also includes other advanced features, such as DNSSEC and intelligent resolution based on many different algorithms.

    The LTM

    is a full reverse proxy, handling connections from clients. The F5 LTM uses Virtual Services(VSs) and Virtual IPs(VIPs) to configure a load balancing setup for a service. LTMs can handle load balancing in two ways, first way is a nPathconfiguration, and second is a Secure Network Address Translation(SNAT) method.

    nPath, the F5 does the job of load balancing by intelligently deciding which server endpoint to pass traffic to. nPath, however, does so by bypassing the F5 in the return path. For example you have two servers 192.168.0.10 and 192.168.0.11, and an F5 listening for this particular set up on VIP 172.16.0.2. Now when the traffic from a client destined for the 172.16.0.2 hits the F5, the F5 intelligently passes it to either 192.168.0.10 or 192.168.0.11. The tricky part is when the traffic leaves from the F5 to either server, the IP packet’s source address is that of the F5. Therefore each server mush have a loopback address configured that matches the F5s source IP address of the interface (on the F5) the original packet leaves from., in this example 172.16.0.2. This prevents each server endpoint from sending it back to the F5 directly and forces the server to use it’s gateway of last resort.

    Secure Network Address Translation(SNAT), is a more common BIGIP F5 implementation. In this scenario the F5 is configured essentially as a reverse-proxy server. Think Many-to-One. Client’s target Virtual IPs that sit in front of a pool of endpoint servers. However, the Client never sees behind the VIP, to there perspective the VIP is the server they are requesting. For example, you have a VIP 192.168.0.55 which routes to an F5 who is listening for requests destined for that IP. The F5 has a configuration in place that knows 4 server endpoints that can serve requests destined for that IP, 10.0.0.5, 10.0.0.6, 10.0.0.6, 10.0.0.7. When a request comes from a client to the VIP the F5 acts as the server for the client. In the back-end the F5 acts as a client sending the identical request to one of the four endpoint servers. The response is then proxied back from the F5 to the “real” client.

    Tying them together.

    GTMs and LTMs used in conjunction with each other provide a robust and resilient, and network optimized environment. This is especially true when dealing with multiple Data Centers or Service Sites. The GTMs will handling the initially network path to take by resolving clients with the best route option. The LTMs will handle the load optimization of the service by logically proxying the endpoint servers.

    Below is a diagram of a typical GTM/LTM setup. In this example, there are two Data Centers, the GTM sites at the front of the Data Centers and hands out the VIP that will handle the client’s request. The LTMs are localized in each Data Center (They don’t have to be :-p) in a High Availability pair. The LTMs will reverse proxy the clients connections with the actual server endpoint.

     
    null