Urbackup GUI no accessible (loading forever)

Check IPTABLES/FIREWALLD (firewalld uses iptables, so don't change iptables manually)

Allow https via firewalld

 firewall-cmd --permanent --add-service=https

 firewall-cmd --reload

 firewall-cmd --list-all

 windows PC ping icmp not working

Windows Firewall -> Inbound Rules -> allow icmp.

Also, if the interface in Network of Windows is marked as “public” instead of “work", then it makes Windows think it is on a public hotspot and it will not give access remotely even if the windows firewall rules allow it (In “Public”-mode it doesn’t read the “Inbound Rules”…)

 Change the interfaces to “Work” or "Private"

In windows defender:

1. Search for Windows Firewall, and click to open it.
2. Click Advanced Settings on the left.
3. From the left pane of the resulting window, click Inbound Rules.
4. In the right pane, find the rules titled File and Printer Sharing (Echo Request - ICMPv4-In)
5. Right-click each rule and choose Enable Rule
6. change remote "local subnet" to "any"

eve-ng : When a node won't start

 

/var/log/syslog shows:

Jun 18 11:21:18 labusraeveng01 iol_wrapper[105334]: 18/5 15:21:18.639 ERR#011Error while connecting local AF_UNIX: No such file or directory /tmp/netio33797/5 (2)

Jun 18 11:21:18 labusraeveng01 iol_wrapper[105334]: 18/5 15:21:18.639 ERR#011Cannot listen at AF_UNIX (5). ERR: Cannot open AF_UNIX sockets (2).

Jun 18 11:21:18 labusraeveng01 iol_wrapper[105334]: 18/5 15:21:18.639 ERR#011Failed to create AF_UNIX socket file (2).

Jun 18 11:21:18 labusraeveng01 iol_wrapper[105334]: 18/5 15:21:18.639 INF#011Caught SIGTERM, killing child.

For some reason the socket in /tmp doesn't exist anymore.

mkdir /tmp/netio33797

python -c "import socket as s; sock = s.socket(s.AF_UNIX); sock.bind('/tmp/netio33797/5')"

chown -R 33797:unl /tmp/netio33797

et voila!

eve-ng network/interface linux issues

 

Sometimes the ip-config of eve-ng itself is deleted (on the linux level)

/var/log/syslog shows:

Jun 18 15:49:13 labusraeveng01 systemd-udevd[104705]: Could not generate persistent MAC address for vun001000000221: No such file or directory

This could be caused by this https://github.com/systemd/systemd/issues/3374. What I did was:
- Add file /etc/systemd/network/99-default.link

- Content:
[Link]
# NamePolicy=kernel database onboard slot path
MACAddressPolicy=none

- Reboot the server

After the reboot:
rm -f /opt/ovf/.configured
su –
and configure networking again.
Check license:
/opt/unetlab/wrappers/unl_wrapper -a fixpermissions
In case the license stays invalid, try:
systemctl restart licserver

You could still see in /var/log/syslog other errors:

Jun 18 16:23:33 labusraeveng01 systemd-udevd[66982]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.

(bug in systemd, should be fixed as of systemd v239) but this seems cosmetic

python virtualenv

 https://www.dabapps.com/blog/introduction-to-pip-and-virtualenv-python/

create virtualenv for your project

$ cd ~/code/myproject/
$ virtualenv env

install python libraries using pip that came with your virtualenv

$ env/bin/pip install <library>
To run python do
$ env/bin/python ...

MD5 Checksum

Windows (cmd)-> Certutil -hashfile <filename> MD5

Linux -> md5sum <filename>

Cisco -> verify /md5 bootflash:<filename>

Cisco Firewall

 

FMC/Firepower Magement Center

                    🔝
Logical Device FTD/Firepower Threat Defense)

                    🔝
Firepower Chassis (4100) -> FXOS CLI or https://managementIP (FCM/Firepower Chassis Manager)

Remarks:

Logical Device can be instance Native (use all resources of the chassis) -> only one FTD is possible. 
Logical Device can be instance Container -> multiple FTDs are possible.
(container creation is only possible from FMC?)

ASDM
🔝
ASA

Troubleshooting:

packet-tracer simulates a flow and shows the result

https://networkology.net/2013/03/06/using-packet-tracer-for-validating-icmp-traffic/

TCP and UDP being statefully inspected by default, you just have to run the packet-tracer on the source interface and you can be sure the return traffic will be allowed through.  With ICMP, it’s a different story.

Because the ASA does not statefully inspect ICMP  packets (by default) you have to vouch for the return packets as well. So you’ll be running two packet-tracer commands to verify that ICMP packets go through and come back.

So here’s how you verify ICMP echo and echo-reply using packet-tracer;

For verifying echo packets, type=8 code=0

packet-tracer input inside icmp 10.1.1.2 8 0 172.21.1.2 detailed

For verifying echo-reply packets, type=0 code=0

packet-tracer input outside icmp 172.21.1.2 0 0 10.1.1.2 detailed

Packet-tracer does more than just inject a 'virtual'  packet into the data-plane. One can also add the 'trace' option to  the capture command, so that actual packets the security appliance  receives (which are matched by the capture) are also traced.

access-list icmp8844 extended permit icmp any4 host 8.8.4.4 
access-list icmp8844 extended permit icmp host 8.8.4.4 any4 
capture myicmp type raw-data access-list icmp8844 trace interface TYPE2-INSIDE
capture myicmpreturn type raw-data access-list icmp8844 trace interface TYPE2-OUTSIDE

To view the packet-trace from captured packet #3 in the capture, use the command:  ASA# "show capture mycap trace packet-number 3"