topic Re: Problem with traffic between 2 interfaces in Network Security

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

gasparmenendez — Fri, 21 Feb 2020 14:15:48 GMT

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.

Re: Problem with traffic between 2 interfaces

Flavio Miranda — Thu, 31 Aug 2017 18:09:12 GMT

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.

Re: Problem with traffic between 2 interfaces

gasparmenendez — Thu, 31 Aug 2017 18:48:14 GMT

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???

Re: Problem with traffic between 2 interfaces

Flavio Miranda — Thu, 31 Aug 2017 20:55:50 GMT

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.

Re: Problem with traffic between 2 interfaces

gasparmenendez — Thu, 31 Aug 2017 21:55:02 GMT

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.

Re: Problem with traffic between 2 interfaces

Flavio Miranda — Thu, 31 Aug 2017 22:07:49 GMT

Nice. The Server reveives and reply the packets.

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

Re: Problem with traffic between 2 interfaces

gasparmenendez — Thu, 31 Aug 2017 22:11:47 GMT

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??

Re: Problem with traffic between 2 interfaces

Flavio Miranda — Thu, 31 Aug 2017 22:33:24 GMT

Try this way:

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

Re: Problem with traffic between 2 interfaces

gasparmenendez — Fri, 01 Sep 2017 14:41:19 GMT

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

Re: Problem with traffic between 2 interfaces

Flavio Miranda — Fri, 01 Sep 2017 20:11:21 GMT

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.

Re: Problem with traffic between 2 interfaces

gasparmenendez — Fri, 01 Sep 2017 20:52:09 GMT

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.

Re: Problem with traffic between 2 interfaces

gasparmenendez — Fri, 01 Sep 2017 21:14:41 GMT

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???

Re: Problem with traffic between 2 interfaces

Flavio Miranda — Fri, 01 Sep 2017 23:38:14 GMT

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.

Re: Problem with traffic between 2 interfaces

Flavio Miranda — Fri, 01 Sep 2017 23:56:40 GMT

Re: Problem with traffic between 2 interfaces

gasparmenendez — Sat, 02 Sep 2017 18:26:42 GMT

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.

Re: Problem with traffic between 2 interfaces

Flavio Miranda — Sat, 02 Sep 2017 18:46:44 GMT

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.

Re: Problem with traffic between 2 interfaces

gasparmenendez — Sat, 02 Sep 2017 18:51:30 GMT

here's capture in the other way:

gaspar@gaspar-Lenovo-ideapad-310-15ISK ~ $ sudo tcpdump -i enp1s0 | grep 10.227.224.8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:49:56.454958 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1239, length 40
13:49:56.454976 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1239, length 40
13:49:57.487287 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1240, length 40
13:49:57.487306 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1240, length 40
13:49:58.519610 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1241, length 40
13:49:58.519624 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1241, length 40
13:49:59.566572 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1242, length 40
13:49:59.566596 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1242, length 40
13:50:00.598874 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1243, length 40
13:50:00.598911 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1243, length 40
13:50:01.632839 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1244, length 40
13:50:01.632855 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1244, length 40
13:50:02.667957 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1245, length 40
13:50:02.667987 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1245, length 40
13:50:03.701705 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1246, length 40
13:50:03.701734 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1246, length 40
13:50:04.738270 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1247, length 40
13:50:04.738287 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1247, length 40
13:50:05.770705 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1248, length 40
13:50:05.770744 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1248, length 40
13:50:06.803582 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1249, length 40
13:50:06.803597 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1249, length 40
13:50:07.835389 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1250, length 40
13:50:07.835402 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1250, length 40
13:50:08.869768 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1251, length 40
13:50:08.869800 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1251, length 40
13:50:09.904622 IP 10.227.224.8 > 192.168.199.30: ICMP echo request, id 1, seq 1252, length 40
13:50:09.904647 IP 192.168.199.30 > 10.227.224.8: ICMP echo reply, id 1, seq 1252, length 40
^C139 packets captured
160 packets received by filter
0 packets dropped by kernel
9 packets dropped by interface

Thanks.

Re: Problem with traffic between 2 interfaces

Flavio Miranda — Sat, 02 Sep 2017 19:17:55 GMT

My las shot man.

Apply this:

same-security-traffic permit inter-interface

Re: Problem with traffic between 2 interfaces

gasparmenendez — Mon, 04 Sep 2017 15:31:06 GMT

Hi friend,

here's ping from 10.227.224.8 to 192.168.199.30 (ASA's ASDM):

6|Sep 04 2017|10:24:34|302015|192.168.199.30|50633|216.58.219.35|443|Built outbound UDP connection 1061824194 for OUTSIDE:216.58.219.35/443 (216.58.219.35/443) to INSIDE_Prueba:192.168.199.30/50633 (170.X.X.2/50633)
6|Sep 04 2017|10:24:34|305011|192.168.199.30|50633|170.X.X.2|50633|Built dynamic UDP translation from INSIDE_Prueba:192.168.199.30/50633 to OUTSIDE:170.X.X.2/50633
6|Sep 04 2017|10:24:34|302013|192.168.199.30|44288|216.58.219.35|443|Built outbound TCP connection 1061824192 for OUTSIDE:216.58.219.35/443 (216.58.219.35/443) to INSIDE_Prueba:192.168.199.30/44288 (170.X.X.2/44288)
6|Sep 04 2017|10:24:34|305011|192.168.199.30|44288|170.X.X.2|44288|Built dynamic TCP translation from INSIDE_Prueba:192.168.199.30/44288 to OUTSIDE:170.X.X.2/44288
6|Sep 04 2017|10:24:34|302016|209.244.0.3|53|192.168.199.30|54863|Teardown UDP connection 1061824150 for OUTSIDE:209.244.0.3/53 to INSIDE_Prueba:192.168.199.30/54863 duration 0:00:00 bytes 110
6|Sep 04 2017|10:24:34|302015|192.168.199.30|54863|209.244.0.3|53|Built outbound UDP connection 1061824150 for OUTSIDE:209.244.0.3/53 (209.244.0.3/53) to INSIDE_Prueba:192.168.199.30/54863 (170.X.X.2/54863)
6|Sep 04 2017|10:24:27|302013|192.168.199.30|54220|54.152.171.205|443|Built outbound TCP connection 1061818984 for OUTSIDE:54.152.171.205/443 (54.152.171.205/443) to INSIDE_Prueba:192.168.199.30/54220 (170.X.X.2/16236)
6|Sep 04 2017|10:24:27|305011|192.168.199.30|54220|170.X.X.2|16236|Built dynamic TCP translation from INSIDE_Prueba:192.168.199.30/54220 to OUTSIDE:170.X.X.2/16236
6|Sep 04 2017|10:24:27|302016|209.244.0.3|53|192.168.199.30|54863|Teardown UDP connection 1061818924 for OUTSIDE:209.244.0.3/53 to INSIDE_Prueba:192.168.199.30/54863 duration 0:00:00 bytes 376
6|Sep 04 2017|10:24:27|302015|192.168.199.30|54863|209.244.0.3|53|Built outbound UDP connection 1061818924 for OUTSIDE:209.244.0.3/53 (209.244.0.3/53) to INSIDE_Prueba:192.168.199.30/54863 (170.X.X.2/54863)
6|Sep 04 2017|10:24:27|302013|192.168.199.30|58414|35.201.97.85|443|Built outbound TCP connection 1061818687 for OUTSIDE:35.201.97.85/443 (35.201.97.85/443) to INSIDE_Prueba:192.168.199.30/58414 (170.X.X.2/58414)
6|Sep 04 2017|10:24:27|305011|192.168.199.30|58414|170.X.X.2|58414|Built dynamic TCP translation from INSIDE_Prueba:192.168.199.30/58414 to OUTSIDE:170.X.X.2/58414
6|Sep 04 2017|10:24:27|302016|209.244.0.3|53|192.168.199.30|54863|Teardown UDP connection 1061818651 for OUTSIDE:209.244.0.3/53 to INSIDE_Prueba:192.168.199.30/54863 duration 0:00:00 bytes 236

this ping is working fine.

Now the ping from 192.168.199.30 to 10.227.224.8 (ASA's ASDM):

4|Sep 04 2017|10:31:46|313004|||||Denied ICMP type=0, from laddr 10.227.224.8 on interface CARRIERS to 192.168.199.30: no matching session
6|Sep 04 2017|10:31:46|302020|10.227.224.8|0|192.168.199.30|4929|Built inbound ICMP connection for faddr 10.227.224.8/0 gaddr 192.168.199.30/4929 laddr 192.168.199.30/4929
6|Sep 04 2017|10:31:46|302021|10.227.224.8|0|192.168.199.30|4929|Teardown ICMP connection for faddr 10.227.224.8/0 gaddr 192.168.199.30/4929 laddr 192.168.199.30/4929
4|Sep 04 2017|10:31:45|313004|||||Denied ICMP type=0, from laddr 10.227.224.8 on interface CARRIERS to 192.168.199.30: no matching session
6|Sep 04 2017|10:31:45|302020|10.227.224.8|0|192.168.199.30|4929|Built inbound ICMP connection for faddr 10.227.224.8/0 gaddr 192.168.199.30/4929 laddr 192.168.199.30/4929
6|Sep 04 2017|10:31:45|302021|10.227.224.8|0|192.168.199.30|4929|Teardown ICMP connection for faddr 10.227.224.8/0 gaddr 192.168.199.30/4929 laddr 192.168.199.30/4929
4|Sep 04 2017|10:31:44|313004|||||Denied ICMP type=0, from laddr 10.227.224.8 on interface CARRIERS to 192.168.199.30: no matching session
6|Sep 04 2017|10:31:44|302020|10.227.224.8|0|192.168.199.30|4929|Built inbound ICMP connection for faddr 10.227.224.8/0 gaddr 192.168.199.30/4929 laddr 192.168.199.30/4929
6|Sep 04 2017|10:31:44|302021|10.227.224.8|0|192.168.199.30|4929|Teardown ICMP connection for faddr 10.227.224.8/0 gaddr 192.168.199.30/4929 laddr 192.168.199.30/4929
4|Sep 04 2017|10:31:43|313004|||||Denied ICMP type=0, from laddr 10.227.224.8 on interface CARRIERS to 192.168.199.30: no matching session
6|Sep 04 2017|10:31:43|302020|10.227.224.8|0|192.168.199.30|4929|Built inbound ICMP connection for faddr 10.227.224.8/0 gaddr 192.168.199.30/4929 laddr 192.168.199.30/4929
6|Sep 04 2017|10:31:43|302021|10.227.224.8|0|192.168.199.30|4929|Teardown ICMP connection for faddr 10.227.224.8/0 gaddr 192.168.199.30/4929 laddr 192.168.199.30/4929
4|Sep 04 2017|10:31:42|313004|||||Denied ICMP type=0, from laddr 10.227.224.8 on interface CARRIERS to 192.168.199.30: no matching session
6|Sep 04 2017|10:31:42|302020|10.227.224.8|0|192.168.199.30|4929|Built inbound ICMP connection for faddr 10.227.224.8/0 gaddr 192.168.199.30/4929 laddr 192.168.199.30/4929
6|Sep 04 2017|10:31:42|302021|10.227.224.8|0|192.168.199.30|4929|Teardown ICMP connection for faddr 10.227.224.8/0 gaddr 192.168.199.30/4929 laddr 192.168.199.30/4929
4|Sep 04 2017|10:31:41|313004|||||Denied ICMP type=0, from laddr 10.227.224.8 on interface CARRIERS to 192.168.199.30: no matching session
6|Sep 04 2017|10:31:41|302020|10.227.224.8|0|192.168.199.30|4929|Built inbound ICMP connection for faddr 10.227.224.8/0 gaddr 192.168.199.30/4929 laddr 192.168.199.30/4929
6|Sep 04 2017|10:31:41|302021|10.227.224.8|0|192.168.199.30|4929|Teardown ICMP connection for faddr 10.227.224.8/0 gaddr 192.168.199.30/4929 laddr 192.168.199.30/4929
4|Sep 04 2017|10:31:40|313004|||||Denied ICMP type=0, from laddr 10.227.224.8 on interface CARRIERS to 192.168.199.30: no matching session
6|Sep 04 2017|10:31:40|302020|10.227.224.8|0|192.168.199.30|4929|Built inbound ICMP connection for faddr 10.227.224.8/0 gaddr 192.168.199.30/4929 laddr 192.168.199.30/4929

maybe that helps...???

anyway regarding what you suggest about same-security-traffic I don't see the point since all my interfaces have different security levels, but I try it anyway.

Thanks.

Re: Problem with traffic between 2 interfaces

Flavio Miranda — Mon, 04 Sep 2017 18:18:05 GMT

Denied ICMP type=0, from laddr 10.227.224.8 on interface CARRIERS to 192.168.199.30: no matching session

Try to allow ICMP on the rules.

Which kind of access do you intend to perform? For TCP/UDP must be working...