<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hello Noel,<div><br></div><div>Thank you for the link. The article is amazing. I went through it and was able to follow all the steps successfully. However, it is a shame that the article has missed to mention how to setup iptables with conntrack.  </div><div><br></div><div>Am I using the conntrack correctly? You mentioned don't use NFLOG, but I'm not sure if this is what you meant me to do: </div><div><br></div><div><font face="monospace, monospace">sudo iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j NFLOG --nflog-group 1 --nflog-prefix "prefix: ESTABLISHED,RELATED"</font></div><div><br></div><div>The result of this is that I still get the destination IP but the source shows as 10.10.10.8.</div><div><br></div><div><b>vim http:///var/log/ulogd_nfct.json</b><br></div><div><br></div><div><font face="monospace, monospace">{"timestamp": "2019-04-19T11:00:35", "dvc": "Netfilter", "orig.ip.protocol": 6, "orig.l4.sport": 57939, "orig.l4.dport": 443, "orig.raw.pktlen": 2364, "orig.raw.pktcount": 21, "reply.ip.protocol": 6, "reply.l4.sport": 443, "reply.l4.dport": 57939, "reply.raw.pktlen": 6438, "reply.raw.pktcount": 13, "ct.mark": 0, "<a href="http://ct.id">ct.id</a>": 43142912, "ct.event": 4, "flow.start.sec": 1555671512, "flow.start.usec": 962666, "flow.end.sec": 1555671635, "flow.end.usec": 803910, "oob.family": 2, "oob.protocol": 0, "src_ip": "10.10.10.8", "dest_ip": "185.76.64.174", "reply.ip.saddr.str": "185.76.64.174", "reply.ip.daddr.str": "172.31.4.4"}</font><br></div><div><br></div><div>I tried once more by deleting the rule above and replacing it with this:</div><div><br></div><div><font face="monospace, monospace">sudo iptables -I FORWARD -m conntrack --ctstate NEW,RELATED,ESTABLISHED</font><br></div><div><br></div><div>But with the same result.</div><div><br></div><div>Am I on the right path or do you think I going into circles with this?</div><div><br></div><div>Many Thanks,</div><div>Houman</div><div><br></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 17 Apr 2019 at 16:27, Noel Kuntze <noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Houman,<br>
<br>
<br>
Use the conntrack input instead, not the nflog one. It solves all your issues. Take a look at the article at <a href="http://regit.org" rel="noreferrer" target="_blank">regit.org</a>[1].<br>
And please don't use iptables -L. Use iptables-save instead.<br>
<br>
Kind regards<br>
<br>
Noel<br>
<br>
[1] <a href="https://home.regit.org/2014/02/logging-connection-tracking-event-with-ulogd/" rel="noreferrer" target="_blank">https://home.regit.org/2014/02/logging-connection-tracking-event-with-ulogd/</a><br>
<br>
Am 17.04.19 um 12:06 schrieb Houman:<br>
> Hello Noel,<br>
> <br>
> Thank you for the tip. I will definitely look into RELP. For now, I finally got it working with a JSON output for testing purposes only. <br>
> <br>
> I added this to the iptables:<br>
> *sudo iptables -I FORWARD ! -i lo -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j NFLOG --nflog-prefix  "Web 80" --nflog-group 1*<br>
> <br>
> Chain INPUT (policy ACCEPT)<br>
> num  target     prot opt source               destination<br>
> 1    ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED<br>
> 2    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https<br>
> 3    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:2022<br>
> 4    ACCEPT     all  --  anywhere             anywhere<br>
> 5    DROP       all  --  anywhere             anywhere             state INVALID<br>
> 6    ACCEPT     udp  --  anywhere             anywhere             udp dpt:isakmp<br>
> 7    ACCEPT     udp  --  anywhere             anywhere             udp dpt:ipsec-nat-t<br>
> 8    DROP       all  --  anywhere             anywhere<br>
> <br>
> Chain FORWARD (policy ACCEPT)<br>
> num  target     prot opt source               destination<br>
> 1    NFLOG      tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN state NEW nflog-prefix  "Web 80" nflog-group 1<br>
> 2    ACCEPT     all  --  ip-10-10-10-0.eu-west-2.compute.internal/24  anywhere             policy match dir in pol ipsec proto esp<br>
> 3    ACCEPT     all  --  anywhere             ip-10-10-10-0.eu-west-2.compute.internal/24  policy match dir out pol ipsec proto esp<br>
> 4    DROP       all  --  anywhere             anywhere<br>
> <br>
> Chain OUTPUT (policy ACCEPT)<br>
> num  target     prot opt source               destination<br>
> <br>
> It works nicely.  BUT the source IP shows as 10.10.10.8<br>
> I was expecting to see my real IP address. What am I missing, please?<br>
> <br>
> I know I can't add it to the INPUT because the VPN is masquerading. I have to put the rule against FORWARD, otherwise, I get no entries in the log. So what to do?<br>
> <br>
> {<br>
>   "timestamp": "2019-04-17T09:37:40.502387",<br>
> "dvc": "My awesome Netfilter firewall",<br>
> "raw.pktlen": 64,<br>
> "raw.pktcount": 1,<br>
> "oob.prefix": "Web 80",<br>
> "oob.time.sec": 1555493860,<br>
> "oob.time.usec": 502387,<br>
> "oob.mark": 0,<br>
> "oob.ifindex_in": 2,<br>
> "oob.ifindex_out": 2,<br>
> "oob.hook": 2,<br>
> "raw.mac_len": 14,<br>
> "oob.family": 2,<br>
> "oob.protocol": 2048,<br>
> "action": "allowed",<br>
> "raw.type": 1,<br>
> "raw.mac.addrlen": 6,<br>
> "ip.protocol": 6,<br>
> "ip.tos": 0,<br>
> "ip.ttl": 63,<br>
> "ip.totlen": 64,<br>
> "ip.ihl": 5,<br>
> "ip.csum": 44141,<br>
> "<a href="http://ip.id" rel="noreferrer" target="_blank">ip.id</a> <<a href="http://ip.id" rel="noreferrer" target="_blank">http://ip.id</a>>": 0,<br>
> "ip.fragoff": 16384,<br>
> "src_port": 55560,<br>
> "dest_port": 80,<br>
> "tcp.seq": 1199851582,<br>
> "tcp.ackseq": 0,<br>
> "tcp.window": 65535,<br>
> "tcp.offset": 0,<br>
> "tcp.reserved": 0,<br>
> "tcp.urg": 0,<br>
> "tcp.ack": 0,<br>
> "tcp.psh": 0,<br>
> "tcp.rst": 0,<br>
> "tcp.syn": 1,<br>
> "tcp.fin": 0,<br>
> "tcp.res1": 0,<br>
> "tcp.res2": 3,<br>
> "tcp.csum": 26423,<br>
> "<a href="http://oob.in" rel="noreferrer" target="_blank">oob.in</a> <<a href="http://oob.in" rel="noreferrer" target="_blank">http://oob.in</a>>": "eth0",<br>
> "oob.out": "eth0",<br>
> "src_ip": "10.10.10.8",<br>
> "dest_ip": "52.85.70.228",<br>
> "mac.saddr.str": "xx",<br>
> "mac.daddr.str": "xx",<br>
> "mac.str": "xx"<br>
> }<br>
> <br>
> Many Thanks,<br>
> Houman<br>
> <br>
> On Tue, 16 Apr 2019 at 21:40, Noel Kuntze <noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:<br>
> <br>
>     Hello Houman,<br>
> <br>
>     I'd keep the logs as text only and stream them to a logging service via RELP (don't use syslog over tcp. It can loose messages. RELP ensures delivery by design.).<br>
>     Unless you really got a boatload of clients (> 4000) on a single system, I doubt you'll run into problems.<br>
> <br>
>     Kind regards<br>
> <br>
>     Noel<br>
> <br>
>     Am 16.04.19 um 22:19 schrieb Houman:<br>
>     > Hello Noel,<br>
>     ><br>
>     > Thank you very much for your detailed answer. I started looking into ulogd2. Tutorials and documentation seem a bit scarce, but I'm sure I will find my way around it eventually. If you have a good recommendation please let me know.<br>
>     ><br>
>     > Do you recommend keeping ulogd2's logs locally or rather feed them into a local LogStash?  I wonder which one is faster and less resource hungry.<br>
>     ><br>
>     > Many Thanks,<br>
>     > Houman<br>
>     ><br>
>     ><br>
>     ><br>
>     ><br>
>     >  <br>
>     ><br>
>     > On Mon, 15 Apr 2019 at 19:26, Noel Kuntze <noel.kuntze+strongswan-users-ml@thermi.consulting> wrote:<br>
>     ><br>
>     >     Hello Houman,<br>
>     ><br>
>     >     No, that is not a layer that strongSwan or freeradius does have access to. You need to log (and account) the user's traffic using, for example, a netflow collector or ulogd2 (which can use Linux's native conntrack connection tracking system) to capture the relevant data. Using ulogd2 is advised, because unless you disabled conntrack for the relevant connections, you are basically guaranteed to get all information from conntrack (unless ulogd2 can't keep up, but then you don't have enough resources, so you have another issue already).<br>
>     ><br>
>     >     Kind regards<br>
>     ><br>
>     >     Noel<br>
>     ><br>
>     >     Am 15.04.19 um 20:13 schrieb Houman:<br>
>     >     > Hello,<br>
>     >     ><br>
>     >     > We got a notification from the German Federal Office for Information Security that one of our users has been using a website with malware to steal personal information and commit online-banking fraud. To cover their tracks they have been using our StrongSwan VPN.<br>
>     >     ><br>
>     >     ><br>
>     >     > We have now blocked the IPs that resolve to the given website to prevent this from happening.  Unfortunately, The freeRadius logs and syslog we have in place are not enough to pinpoint it to the exact culprit.<br>
>     >     ><br>
>     >     ><br>
>     >     > Is there a way to run strongswan with maximum verbose logs to see which EAP-Radius user has been accessing which IP address at what time? We would like to ban users like this in future.<br>
>     >     ><br>
>     >     ><br>
>     >     > From Freeradius we get to see the acctstartdate, acctupdatedate and acctstopdate but there is no way to relate this to their activities.<br>
>     >     ><br>
>     >     ><br>
>     >     ><br>
>     >     > Many Thanks,<br>
>     >     ><br>
>     >     > Houman<br>
>     ><br>
> <br>
<br>
</blockquote></div>