Disclaimer

The content of this material are challenges faced onsite and how I personally resolved them. Please be noted that solutions posted here

1> should not be considered as ultimate. The material may be considered for reference only.

2> should not be considered as guarantee that solutions may work. Contact Cyberoam support before making any changes.

3> blog does NOT belong to the Cyberoam. It's a blog...a personal blog.

Changes done after referring this site may seriously damage the network. So...

........DO CHANGES AT YOUR OWN RISK

(please contact cyberoamsupport before implementing any changes)
Showing posts with label CLI. Show all posts
Showing posts with label CLI. Show all posts

Friday, 17 February 2012

Back up over VPN to mail server

Below is the Scenario, which was requested recently by one of my customer. They wanted a regular backup being sent to the mail server automatically. It would have been simpler if they wanted backup being sent on the WAN IP of the mail server. Instead, they wanted it over the VPN to the HO and to the mail server behind HO CR: 






Here are the steps need to be done on the BO CR (nothing to be configured on the HO CR)

Step 1> Drop the VPN tunnel (do not delete it, just deactivate the tunnel)


Step 2> set advanced-firewall cr-traffic-nat add destination 192.168.1.5 netmask
255.255.255.255 snatip 192.168.2.1

(the above command is used when the CR initiated traffic has to be sent with different source IP address. By default it sends the traffic with WAN IP address and its sent via WAN port. If you have multiple lan interface then choose the interface ip whose subnet has been published in the VPN tunnel. You want to know where else you can use this command: Check out this link)

Step 3> cyberoam ipsec_route add host 192.168.1.5 tunnelname VPN_BO_2_HO

(As discussed in the earlier, the default behavior is to send the traffic over the Wan physical interface. However, in this case we want to send the CR initiated traffic being sent on VPN interface(logical interface).)

Step 4> Get the tunnel up. And you should be able to telnet you mail server successfully on the private IP address from the BO CR.









Traffic for virtual host: explained




Above is the tcpdump which shows the TCP triple handshake of the process:
1>     The first packet with time stamp as 19:44:44.524107 Packet hits the CR on PORT B (IN) from 10.103.4.250 with source port as 59261 and its going to 10.103.4.11 and destination port is 3389. The flags sets are SYN[S]. The sequence number of the packet is 10988617 and window size of the packet is 8192. You can also find the MSS of the packet as 1460.
2>     CR has now changed the destination IP of the packet as the internal server IP i.e. 10.10.1.2 from 10.103.4.11 and the destination port still remain the same as 3389 and other parameters are still same. The time stamp of the packet is 19:44:44.524276
3>     The third packet with time stamp as 19:44:44.524606 is the SYN/ACK packet received from the 10.10.1.2 with SYN as 2506618164 and the ACK as 10988618.
4>     The third packet source IP will be NAT with 10.103.4.11 and sent out on port B. This packet is still SYN/ACK with time stamp 19:44:44.524679
5>     The packet received is final ACK of the tcp triple handshake with ACK. The time stamp of this packet is 19:44:44.528029
6>     Sixth packet is the inbound NAT to the internal server.

TCPDUMP

I wanted to understand what these CR guys are using in the CLI when using TCPDUMP. These guys check the packets and let us know the result. Here are some of the scenarios and commands which I use for my analysis.

1>To check the traffic coming from a particular source IP:

tcpdump "host <ipaddress>"    like  tcpdump "host 192.168.1.1"

2> If you are only checking the ping traffic

tcpdump "host 192.168.1.1 and proto ICMP"

3> if you are searching for traffic coming from a particular host and particular port

tcpdump "host 192.168.1.1 and port 80"

4> you can get more creative, like you are already connected to CR GUI on port 80 from IP 192.168.1.1 and you do not want port 80 traffic in you dump.

tcpdump "host 192.168.1.1 and port !80"

5> If you want to have the whole packet in the dump

tcpdump "host 192.168.1.1 -s 4096"

6> in case of virtual host:
            a> you should always check the tcpdump on the source (source for me here is, I am right in my office and my customer complained about virtual host not working. So when I am going to hit his public IP on port 80 from my browser, I should see traffic with source IP as my public IP and the destination as the customer public IP)

tcpdump "host 81.32.45.67 and port 80"

Also note that when you are doing it, try taking the access of the Cyberoam on https and port 22(ssh)

7> you can also use || (2 pipe) for or statement

tcpdump "host 192.168.1.1 || host 192.168.1.2 || port 80"

8> You can use the same statements in the GUI as well to check if the packets are being dropped:
 System-> diagnostices-->packet capture
use the filter within the double quotes and it should be filtering the traffic.



Saturday, 17 December 2011

CLI Commands of Cyberoam

In this post I will try explaining the CLI commands used in the Cyberoam and how they will help in resolving the issues.