Problem with traffic between 2 interfaces, Still no solution...

[gasparmenendez]

Hi folks,

I'm having trouble with traffic between different subnets connected to different interfaces. In interface CARRIERS is connected a server with ip address 10.227.224.11 and in interface INSIDE_Prueba I have connected my PC with ip address 192.168.199.30. I can't ping from my PC to the server, it doesn't answer. However, I can see in my ASA's ASDM (5580 8.4(5) and Device Manager Version 7.1(1)52) the Hit counter increasing when I send ping. Here's what I configured:

access-list INSIDE_Prueba_access_out extended permit ip 10.227.224.0 255.255.252.0 any (here's where the counter increases)

and

access-list CARRIERS_access_out extended permit ip 192.168.199.0 255.255.255.0 10.227.224.0 255.255.252.0

Can anybody help me please??

Thanks in advance.

[Flavio Miranda]

How many interface does your server has and what about the server´s rouintg table?

Looks like the server has no clue how to send the packe back.

[gasparmenendez]

the server has only one interface, and about routing this is what is configured:

root@cacti-carrier:/home/gaspar# ip route show
default via 10.227.224.3 dev eth0

anyway, the above doesn't imply that everything is send back through 10.227.224.3 that is ip address of CARRIERS interface???

[Flavio Miranda]

Should be the Firewalls IP address. But, if this server has only one interface and considering it is communication on the network, routing should be not the problem.

 Looks like this is a Unix like server. Can you run tcpdump -i eth0 while ping it from PC ?

This should be a good way to see what´s going on with the incoming packets.

[gasparmenendez]

I ran tcpdump -i eth0 | grep 192.168.199.31 and got this:

root@cacti-carrier:/home/gaspar# tcpdump -i eth0 | grep 192.168.199.31
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:45:16.070042 IP 192.168.199.31 > 10.227.224.11: ICMP echo request, id 1, seq 172, length 40
16:45:16.070085 IP 10.227.224.11 > 192.168.199.31: ICMP echo reply, id 1, seq 172, length 40
16:45:20.624536 IP 192.168.199.31 > 10.227.224.11: ICMP echo request, id 1, seq 173, length 40
16:45:20.624579 IP 10.227.224.11 > 192.168.199.31: ICMP echo reply, id 1, seq 173, length 40
16:45:25.633785 IP 192.168.199.31 > 10.227.224.11: ICMP echo request, id 1, seq 174, length 40
16:45:25.633831 IP 10.227.224.11 > 192.168.199.31: ICMP echo reply, id 1, seq 174, length 40
16:45:30.632989 IP 192.168.199.31 > 10.227.224.11: ICMP echo request, id 1, seq 175, length 40
16:45:30.633035 IP 10.227.224.11 > 192.168.199.31: ICMP echo reply, id 1, seq 175, length 40
16:45:35.632806 IP 192.168.199.31 > 10.227.224.11: ICMP echo request, id 1, seq 176, length 40
16:45:35.632855 IP 10.227.224.11 > 192.168.199.31: ICMP echo reply, id 1, seq 176, length 40
16:45:40.631813 IP 192.168.199.31 > 10.227.224.11: ICMP echo request, id 1, seq 177, length 40
16:45:40.631829 IP 10.227.224.11 > 192.168.199.31: ICMP echo reply, id 1, seq 177, length 40
16:45:45.633666 IP 192.168.199.31 > 10.227.224.11: ICMP echo request, id 1, seq 178, length 40
16:45:45.633703 IP 10.227.224.11 > 192.168.199.31: ICMP echo reply, id 1, seq 178, length 40
16:45:50.626219 IP 192.168.199.31 > 10.227.224.11: ICMP echo request, id 1, seq 179, length 40
16:45:50.626264 IP 10.227.224.11 > 192.168.199.31: ICMP echo reply, id 1, seq 179, length 40
^C117 packets captured
120 packets received by filter
0 packets dropped by kernel

but I don't know how to read it.

[Flavio Miranda]

Nice. The Server reveives and reply the packets.

 Something worng with wrong with firewall rule. Sure you permited both direction?

[gasparmenendez]

here are the lines on the ASA regarding this issue:

access-list CARRIERS_access_in extended permit ip 10.227.224.0 255.255.252.0 any
access-list CARRIERS_access_out extended permit ip 192.168.199.0 255.255.255.0 10.227.224.0 255.255.252.0
access-list CARRIERS_access_out extended permit ip any 10.227.224.0 255.255.252.0

.

.

.

access-list INSIDE_Prueba_access_out extended permit ip 10.227.224.0 255.255.252.0 any

should I have something else??

[Flavio Miranda]

Try this way:

access-list CARRIERS_access_in extended permit ip 10.227.224.0 255.255.252.0 any 
access-list CARRIERS_access_out extended permit ip 192.168.199.0 255.255.255.0 10.227.224.0 255.255.252.0 
access-list CARRIERS_access_out extended permit ip any 10.227.224.0 255.255.252.0

access-list INSIDE_Prueba_access_out extended permit ip 192.168.199.0 255.255.255.0  any

access-list INSIDE_Prueba_access_in  extended permit ip 10.227.224.0 255.255.252.0 192.168.199.0 255.255.255.0

[gasparmenendez]

I did what you suggest but still no luck my friend....

[Flavio Miranda]

Gaspar,

 Try to put a capture on both direction to see.

 We saw that the packet is hiring the server and it is replying.

 The server has only one interface, so routing must not be the problema.

 You have the ACL correctly placed.

 We need log to figure it out. If I remember, you saw hits in one direction, but we need to see capture logs.

 Hit means the packet got to the interface now we need to se if it was permitted or denied from server to PC.

[gasparmenendez]

let me check to run the tcpdump in windows. I'll get back to you in the minute I've got what you ask.

Thanks.

[gasparmenendez]

Holy cr....! I didn't realize that ping in the other way works fine!! I ping the PC (192.168.199.31) from the server (10.227.224.11) and works fine!! the problem is the other way around...

do you still need to capture traffic???

[Flavio Miranda]

That's interesting. Cause the ping from PC is also getting in to the server as we could see on tcpdump..Right?

Put capture both directions and lets see.

[gasparmenendez]

Hi Flavio,

is near impossible to get some working tool for tcpdump in Windows, honestly I'm about to give up on that.

Anyway as an additional information, I was checkinfg the server and found out it has a firewall (firewall.sh) service running. I tried to stop service but nothing changed (I can't be sure if service really stopped or not). Here's the firewall.sh file:

#!/bin/bash

iptables -F
iptables -X

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -s 0/0 -p tcp --dport 8443 -j ACCEPT
iptables -A INPUT -s 0/0 -p tcp --dport 1157 -j ACCEPT
iptables -A INPUT -s 10.227.224.0/22 -p udp --dport 514 -j ACCEPT
iptables -A INPUT -s 10.227.224.0/22 -p udp --dport 161:162 -j ACCEPT
iptables -A INPUT -s 0/0 -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -s 0/0 -p icmp --icmp-type echo-reply -j ACCEPT

iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 4 -j DROP
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
iptables -A INPUT -p icmp -j DROP

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

maybe this would help.

Thanks.

[Flavio Miranda]

I was refering to capture on ASA.

But, if you are using ASDM, you can see there as well. The idea is just see how firewall is processing packets against rules.

 As per tcpdump, you server is not denying icmp and, if you are ping the PC from server, PC is not denying either.