Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect half-way destination address shown for port-forwarded ASA flows #1398

Closed
qm2k opened this issue Aug 9, 2017 · 15 comments
Closed

Comments

@qm2k
Copy link

qm2k commented Aug 9, 2017

Please see 2017-08-09.pcap.gz. It includes just two flows. First flow (533847104) is shown for comparison, it has no port forwarding and does not cause problems. Second flow (533847166) utilizes port-forwarding. Here's information about it as decoded by Wireshark:

Flow Id: 533847166
SrcAddr: 10.7.7.99 (10.7.7.99)
SrcPort: 45968
InputInt: 15
DstAddr: 83.69.211.186 (83.69.211.186)
DstPort: 22
OutputInt: 15
Protocol: 6
IPv4 ICMP Type: 0
IPv4 ICMP Code: 0
Post NAT Source IPv4 Address: 10.4.1.4 (10.4.1.4)
Post NAT Destination IPv4 Address: 10.6.77.241 (10.6.77.241)
Post NAPT Source Transport Port: 45968
Post NAPT Destination Transport Port: 22
Firewall Event: Flow created (1)
Extended firewall event code: ignore (0)
Observation Time Milliseconds: Aug  9, 2017 19:05:54.246000000 MSK
Ingress ACL ID: a573c83eccef216b00000000
Egress ACL ID: 2364199b6dcb35fe00000000
AAA username: 
StartTime: Aug  9, 2017 19:05:54.246000000 MSK

Here port 22 of ASA address 83.69.211.186 is forwarded to port 22 of internal host 10.6.77.241. For this kind of flows ntopng currently shows 83.69.211.186 as destination. This is incorrect, the destination is actually 10.6.77.241, and 83.69.211.186 is just an ASA's address where connection is routed.

Thus, in place of DstAddr the Post NAT Destination IPv4 Address field must be used. Likewise for port in place of DstPort the Post NAPT Destination Transport Port must be used (they can be different depending on port forwarding rules).

@simonemainardi
Copy link
Contributor

Implemented as a preference under Interfaces:

image

As you can see now (by using the pcap provided) both src and dst ips and ports are those in the post-nat:

image

simone@devel:~/nProbe$ ./nprobe -i none -n none --collector-port 2055 -b 2 -T="%IPV4_SRC_ADDR %IPV4_DST_ADDR %IPV4_SRC_MASK %IPV4_DST_MASK %L4_SRC_PORT %L4_DST_PORT %IPV6_SRC_ADDR %IPV6_DST_ADDR %IPV6_SRC_MASK %IPV6_DST_MASK %IP_PROTOCOL_VERSION %SRC_TOS %PROTOCOL %ICMP_TYPE %INPUT_SNMP %SRC_AS %DST_AS %IPV4_NEXT_HOP %IPV6_NEXT_HOP %TCP_FLAGS %OUTPUT_SNMP %IN_BYTES %IN_PKTS %OUT_BYTES %OUT_PKTS %MIN_TTL %MAX_TTL %FIRST_SWITCHED %LAST_SWITCHED  %EXPORTER_IPV4_ADDRESS %IN_SRC_MAC %IN_DST_MAC %POST_NAT_SRC_IPV4_ADDR %POST_NAT_DST_IPV4_ADDR %POST_NAPT_SRC_TRANSPORT_PORT %POST_NAPT_DST_TRANSPORT_PORT" --zmq tcp://127.0.0.1:5556 --zmq-probe-mode  -V 10 --json-labels

sudo ./ntopng  -i "tcp://*:5556c"  -m "0.0.0.0/0"

New builds will be available tomorrow.

@qm2k
Copy link
Author

qm2k commented Sep 14, 2017

Somehow I do not see (post-NAT data) it at least for WAN->LAN connections. I provided LAN->LAN example, it is possible that it is different, or the fix does not work. Will follow up with more data.

@simonemainardi
Copy link
Contributor

I tested with the pcap provided and it works. Remember that you have to upgrade nprobe as well, not just ntopng.

If you experience some other issues, please make sure to provide a pcap so I can reproduce

@qm2k
Copy link
Author

qm2k commented Sep 18, 2017

If you experience some other issues, please make sure to provide a pcap so I can reproduce

Ok. Will be able to do tests and captures next weekend (I hope).

@qm2k
Copy link
Author

qm2k commented Sep 23, 2017

Please see pcap and screenshots here . There're 4 flows there:

  • 600113499: LAN to WAN with dynamic NAT but no port forwarding. Ports and hosts are correct, but client and server are mixed up (interchanged) which also needs fixing.
  • 600114936: WAN to LAN with port forwarding. It may be not clear on screenshot due to reverse name resolution, but mapped IP address is shown in place of real IP.
  • 600118863: LAN to LAN with dynamic NAT and port forwarding. This one is not screenshotted, please see next.
  • 600120849: LAN to LAN with dynamic NAT and port forwarding. Again, it may be not clear on screenshot due to reverse name resolution, but mapped IP address is shown in place of target real IP.

P.S. Here's how Network Interfaces page looks like:
screenshot from 2017-09-23 15 57 28

@qm2k
Copy link
Author

qm2k commented Sep 23, 2017

P.S. Re-did all tests with second switch (Use Post-Nat Source IPv4 Addresses and Ports) off. Nothing changed.

@qm2k
Copy link
Author

qm2k commented Sep 28, 2017

Re-tested on v.3.1.170928 with same (first on, second off) and reverse (first off, second on) switches position. Same results.

@simonemainardi
Copy link
Contributor

600113499: LAN to WAN with dynamic NAT but no port forwarding. Ports and hosts are correct, but client and server are mixed up (interchanged) which also needs fixing.

image

actually it looks ok (please compare the flow with client/servers and post-nat addresses in wireshark)

@simonemainardi
Copy link
Contributor

600114936: WAN to LAN with port forwarding. It may be not clear on screenshot due to reverse name resolution, but mapped IP address is shown in place of real IP.

image

everything looks correct here as well. The destination address is overridden with its post-nat 10.xxx IP address as specified in the settings.

@simonemainardi
Copy link
Contributor

600118863: LAN to LAN with dynamic NAT and port forwarding. This one is not screenshotted, please see next.

image

also LAN to LAN is ok as the post nat src and dst addresses properly ovverride the src and dst addresses

@simonemainardi
Copy link
Contributor

600120849: LAN to LAN with dynamic NAT and port forwarding. Again, it may be not clear on screenshot due to reverse name resolution, but mapped IP address is shown in place of target real IP.

image

also this is consistent with the expected behavior as you can see from the screen capture.

For the sake of completeness, here is the nprobe configuration I have used to to the tests:

[simone@develv5 nProbe]$ ./nprobe  -i none -n none --collector-port 2056 -b 2 -T="%IPV4_SRC_ADDR %IPV4_DST_ADDR %IPV4_SRC_MASK %IPV4_DST_MASK %L4_SRC_PORT %L4_DST_PORT %IPV6_SRC_ADDR %IPV6_DST_ADDR %IPV6_SRC_MASK %IPV6_DST_MASK %IP_PROTOCOL_VERSION %SRC_TOS %PROTOCOL %ICMP_TYPE %INPUT_SNMP %SRC_AS %DST_AS %IPV4_NEXT_HOP %IPV6_NEXT_HOP %TCP_FLAGS %OUTPUT_SNMP %IN_BYTES %IN_PKTS %OUT_BYTES %OUT_PKTS %MIN_TTL %MAX_TTL %FIRST_SWITCHED %LAST_SWITCHED  %EXPORTER_IPV4_ADDRESS %IN_SRC_MAC %IN_DST_MAC %POST_NAT_SRC_IPV4_ADDR %POST_NAT_DST_IPV4_ADDR %POST_NAPT_SRC_TRANSPORT_PORT %POST_NAPT_DST_TRANSPORT_PORT" --zmq tcp://127.0.0.1:5557 --zmq-probe-mode  -V9 --json-labels

@qm2k
Copy link
Author

qm2k commented Oct 3, 2017

It is working on your screenshots, but not in my system. But I didn't change nprobe conf/command line, only ntopng settings (didn't realize I should). Will come back after testing with -T.

@qm2k
Copy link
Author

qm2k commented Oct 4, 2017

I've added 3 more lines to /etc/nprobe/nprobe-none.conf, it now looks like this:

--zmq="tcp://127.0.0.1:5556"
--collector-port=2055
--collector=none
--interface=none
--lifetime-timeout=90
--flow-templ="%IPV4_SRC_ADDR %IPV4_DST_ADDR %IPV4_SRC_MASK %IPV4_DST_MASK %L4_SRC_PORT %L4_DST_PORT %IPV6_SRC_ADDR %IPV6_DST_ADDR %IPV6_SRC_MASK %IPV6_DST_MASK %IP_PROTOCOL_VERSION %SRC_TOS %PROTOCOL %ICMP_TYPE %INPUT_SNMP %SRC_AS %DST_AS %IPV4_NEXT_HOP %IPV6_NEXT_HOP %TCP_FLAGS %OUTPUT_SNMP %IN_BYTES %IN_PKTS %OUT_BYTES %OUT_PKTS %MIN_TTL %MAX_TTL %FIRST_SWITCHED %LAST_SWITCHED  %EXPORTER_IPV4_ADDRESS %IN_SRC_MAC %IN_DST_MAC %POST_NAT_SRC_IPV4_ADDR %POST_NAT_DST_IPV4_ADDR %POST_NAPT_SRC_TRANSPORT_PORT %POST_NAPT_DST_TRANSPORT_PORT"
--flow-version=9
--json-labels

Problems with IP-addresses are gone, but traffic values are now completely wrong: right now Top Local Talkers contains 405.52 Mbit/s in the first line (on a 100 Mbit/s interface), Top Remote Destinations 4.05 kbit/s, and Top Application Traffic is two digits kbits. Looks like some of the field values are taken from wrong places. Do you know what I'm doing wrong and/or how can I verify correctness of template used?

@simonemainardi
Copy link
Contributor

try to remove --flow-version as well.

Apart from the throughput values that you mentioned, are the total values of bytes and packets correct?

@qm2k
Copy link
Author

qm2k commented Oct 4, 2017

Removing --flow-version did not help. When I list specific flows, their Total Bytes value looks correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants