Failed to lookup target ether, without error from logpkt_ether_lookup

[annadevries1992]

Hello,

When i try to send the log/capt output to a specific IP address which is defined on the local host, it tries for 1 minute and fails with message "Failed to lookup target ether".
But none of the error messages from the logpkt_ether_lookup( show up, so i can't see why it failed.

• When looking at the arp table, 10.1.1.2 has a valid entry on one of the local interfaces, and also responds to ping requests.
• But when setting one of the LAN systems as -T target, it works fine.

Any hints on what i'm doing wrong ;-) ?

--

sslsplit -k /root/gw.key -c /root/gw.crt -I ue0 -T 10.1.1.2 -D https 127.0.0.1 8080

SSLsplit 0.5.5-12-ge17de84-dirty (built 2022-08-08)
Build info: V:GIT
Features: -DDEBUG_OPTS -DDEBUG_PROXY -DHAVE_IPFW -DHAVE_PF
NAT engines: pf* ipfw
Local process info support: yes (FreeBSD sysctl)
compiled against LibreSSL 3.3.6 (20000000)
rtlinked against LibreSSL 3.3.6 (20000000)
OpenSSL API provided by LibreSSL: LibreSSL 3.3.6 (3030600f)
OpenSSL has support for TLS extensions
TLS Server Name Indication (SNI) supported
OpenSSL is thread-safe with THREADID
OpenSSL has no engine support
Using SSL_MODE_RELEASE_BUFFERS
SSL/TLS protocol availability: tls10 tls11 tls12
SSL/TLS algorithm availability: !SHA0 RSA DSA ECDSA DH ECDH EC
OpenSSL option availability: SSL_OP_NO_COMPRESSION SSL_OP_NO_TICKET SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION SSL_OP_TLS_ROLLBACK_BUG
compiled against libevent 2.1.12-stable
rtlinked against libevent 2.1.12-stable
compiled against libnet 1.1.6
rtlinked against libnet 1.1.6
compiled against libpcap n/a
rtlinked against libpcap 1.9.1
2 CPU cores detected
Generated 2048 bit RSA key for leaf certs.
SSL/TLS protocol: negotiate
proxyspecs:

• [127.0.0.1]:8080 ssl|http pf
  Loaded CA: '/C=NL/ST=gw/L=gw/O=gw/[email protected]/CN=GW-ca'
  SSL/TLS leaf certificates taken from:
• Generated on the fly
  Failed to lookup target ether
  sslsplit: failed to preinit logging.

--
SSLsplit 0.5.5-12-ge17de84-dirty (built 2022-08-08)
Copyright (c) 2009-2019, Daniel Roethlisberger [email protected]
https://www.roe.ch/SSLsplit
Build info: V:GIT
Features: -DDEBUG_OPTS -DDEBUG_PROXY -DHAVE_IPFW -DHAVE_PF
NAT engines: pf* ipfw
Local process info support: yes (FreeBSD sysctl)
compiled against LibreSSL 3.3.6 (20000000)
rtlinked against LibreSSL 3.3.6 (20000000)
OpenSSL API provided by LibreSSL: LibreSSL 3.3.6 (3030600f)
OpenSSL has support for TLS extensions
TLS Server Name Indication (SNI) supported
OpenSSL is thread-safe with THREADID
OpenSSL has no engine support
Using SSL_MODE_RELEASE_BUFFERS
SSL/TLS protocol availability: tls10 tls11 tls12
SSL/TLS algorithm availability: !SHA0 RSA DSA ECDSA DH ECDH EC
OpenSSL option availability: SSL_OP_NO_COMPRESSION SSL_OP_NO_TICKET SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION SSL_OP_TLS_ROLLBACK_BUG
compiled against libevent 2.1.12-stable
rtlinked against libevent 2.1.12-stable
compiled against libnet 1.1.6
rtlinked against libnet 1.1.6
compiled against libpcap n/a
rtlinked against libpcap 1.9.1
2 CPU cores detected

--
FreeBSD 13.1-RELEASE stable/22.7-n250212-a26d6065f1f SMP amd64

[sonertari]

For ether lookup to succeed, 10.1.1.2 must be reachable on ue0. Can you make sure it is:

ping -I ue0 10.1.1.2

[annadevries1992]

Hi Sonertari,

Thanks for helping out :)

Ping -I , option is only for multicast addresses on FBSD. It doesn't allow a ping to a specific address.

10.1.1.2 is defined as an alias/32 on the ue0 interface.
main address is 10.1.1.1/24. And when setting that 10.1.1.1 as -T target in sslsplit, it also fails after trying for 1 minute.

The idea is to feed Suricata via ue0 with decrypted data from user SSL connections.
while the actual SSL traffic goes out on interface em0.

[annadevries1992]

Is there a way to just tell/config sslsplit what the mirror target mac/arp address is ?
So it doesn't have to try to look it up.

[sonertari]

You sound like you know what you are doing, but what happens if you use the -S option on FBSD:

ping -S <IPv4 address of ue0> 10.1.1.2

Currently sslsplit does not support an ether address option for mirror targets.

As you can see in logpkt_ether_lookup(), we send arp requests to see if the mirror target is up. I guess we get the ether address of 10.1.1.2 ue0 successfully, because libnet_get_hwaddr() does not error out. So I guess we cannot receive any reply to our arp requests (max 50 tries).

[annadevries1992]

Trying to find the source of the issue..
Any ideas on, which specific funtion might fail to resolve the needed info, when "logpkt_ether_lookup(" doesn't state an error message itself.

ping -S 10.1.1.1 10.1.1.2

PING 10.1.1.2 (10.1.1.2) from 10.1.1.1: 56 data bytes
64 bytes from 10.1.1.2: icmp_seq=0 ttl=64 time=0.069 ms
64 bytes from 10.1.1.2: icmp_seq=1 ttl=64 time=0.108 ms

arp -an

(10.1.1.2) at 94:10:3e:b8:78:8a on ue0 permanent [ethernet]
(10.1.1.1) at 94:10:3e:b8:78:8a on ue0 permanent [ethernet]
(10.1.1.6) at 00:15:65:c3:a0:8f on ue0 expires in 1176 seconds [ethernet]
(10.1.1.4) at 9c:c7:a6:cb:c8:53 on ue0 expires in 1092 seconds [ethernet]
(192.168.4.1) at 00:1d:aa:44:cd:60 on em0 expires in 1181 seconds [ethernet]
(192.168.4.2) at a0:b3:cc:2a:ac:58 on em0 permanent [ethernet]

ifconfig -a

em0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: Achterhuis
options=4802008<VLAN_MTU,WOL_MAGIC,NOMAP>
ether a0:b3:cc:2a:ac:58
inet 192.168.4.2 netmask 0xffffff00 broadcast 192.168.4.255
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff000000
groups: lo
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
enc0: flags=0<> metric 0 mtu 1536
groups: enc
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
pfsync0: flags=0<> metric 0 mtu 1500
syncpeer: 0.0.0.0 maxupd: 128 defer: off
syncok: 1
groups: pfsync
pflog0: flags=20100<PROMISC,PPROMISC> metric 0 mtu 33160
groups: pflog
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: Voorhuis
options=80000
ether 94:10:3e:b8:78:8a
inet 10.1.1.1 netmask 0xffffff00 broadcast 10.1.1.255
inet 10.1.1.2 netmask 0xffffffff broadcast 10.1.1.2
media: Ethernet autoselect
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

[sonertari]

Give it to my ignorance, but I don't understand the following lines in the ifconfig output for the ue0 interface:

inet 10.1.1.1 netmask 0xffffff00 broadcast 10.1.1.255
inet 10.1.1.2 netmask 0xffffffff broadcast 10.1.1.2

So, 10.1.1.2 is one of the IP addresses of the ue0 interface itself, which means that you are trying to mirror the packets to the same interface itself. Right? (Yes, we can ping our own IP address.)

The only way I can see logpkt_ether_lookup() can fail without giving any extra info is if the loop at the bottom reaches 50 trials. This means that the logpkt_recv_arp_reply() handler is failing, which also does not give any reasons.

So, I would recommend inserting a couple of debug prints in logpkt_recv_arp_reply() to see why it exits (if we really receive any arp replies at all). And also one more debug print after the do/while loop to confirm my theory that ctx.result is non-zero.

[annadevries1992]

Thank you for looking into it,! and giving pointers on where to look :) I'll dive into that section and try to add some debugging output to investigate what's going on. PS. I know it's one odd setup with traffic on one interface :) Am trying to do something funky whereby the traffic will actually flow without going to a real hardware interface, and if it works.. in the end it may be a cool way to get pfsense and opnsense firewall nasty_traffic detection to a far higher level. But.. for now its playing with stuff to figure things out..

…

On Wed, 10 Aug 2022 11:49:29 -0700 Soner Tari ***@***.***> wrote: Give it to my ignorance, but I don't understand the following lines in the ifconfig output for the ue0 interface: > inet 10.1.1.1 netmask 0xffffff00 broadcast 10.1.1.255 > inet 10.1.1.2 netmask 0xffffffff broadcast 10.1.1.2 So, 10.1.1.2 is one of the IP addresses of the ue0 interface itself, which means that you are trying to mirror the packets to the same interface itself. Right? (Yes, we can ping our own IP address.) The only way I can see logpkt_ether_lookup() can fail without giving any extra info is if the loop at the bottom reaches 50 trials. This means that the logpkt_recv_arp_reply() handler is failing, which also does not give any reasons. So, I would recommend inserting a couple of debug prints in logpkt_recv_arp_reply() to see why it exits (if we really receive any arp replies at all). And also one more debug print after the do/while loop to confirm my theory that ctx.result is non-zero.