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

from sslsplit.

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.

from sslsplit.

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.

from sslsplit.

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).

from sslsplit.

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

from sslsplit.

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.

from sslsplit.

from sslsplit.