Re: Issue with packets routing/forwarding
- Reply: kaycee gb : "Re: Issue with packets routing/forwarding"
- In reply to: kaycee gb : "Issue with packets routing/forwarding"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 11 Sep 2021 11:59:05 UTC
Hello, As I said on my previous message, with the configuration below, routing traffic via ue0 (mobile data) works. Once I delete ue0 routes (so using default routes for everything), I use the adsl line and traffic from the jail do not works anymore. But ... Le Thu, 9 Sep 2021 20:02:18 +0200, kaycee gb <kisscoolandthegangbang@hotmail.fr> a écrit : > At the top of my pf.conf file, I have these lines > > ... > > no nat on $VSW from $proxout > > nat on $phone_if tag PROXOUT tagged PROXOUTNAT -> ( $phone_if ) > > nat on $lan_if tag PROXOUT tagged PROXOUTNAT -> $lan_ip > > > > pass out log quick on $VSW \ > > proto tcp from $proxout to port {80, 443} user 100 tag PROXOUT100 no state > > pass in log quick on $VSW tagged PROXOUT100 tag PROXOUTNAT rtable 0 > > pass out log quick on $phone_if tagged PROXOUT rtable 0 > > pass out log quick on $lan_if tagged PROXOUT rtable 0 > > > > block log quick from 109.0.64.169 > > block log quick to 109.0.64.169 > ... if I change pf configuration from above to this: > table <t_nonat> const {192.168.1.0/24, 172.16.93.0/24 } > no nat on $VSW from $proxout to <t_nonat> > nat on $VSW from $proxout tag PROXOUTVSW -> $lan_ip > nat log on $phone_if from any to any -> ( $phone_if ) > > pass out log quick on $VSW \ > proto tcp to port {80, 443} tagged PROXOUTVSW user 100 rtable 0 no state > block log quick from 109.0.64.169 > block log quick to 109.0.64.16 traffic from jail works as expected via adsl line. If I add some routes via mobile network, this traffic do not works. I see packets that leave host via ue0 interface natted to $lan_ip. I am unable to catch and nat that traffic a second time (even with the "no state" option in pass rule). > # tcpdump -qni ue0 host 109.0.64.169 and port 80 > 13:44:23.687040 IP 192.168.1.50.62336 > 109.0.64.169.80: tcp 0 > 13:44:26.960826 IP 192.168.1.50.63442 > 109.0.64.169.80: tcp 0 > 13:44:29.960986 IP 192.168.1.50.63442 > 109.0.64.169.80: tcp 0 > 13:44:33.162041 IP 192.168.1.50.63442 > 109.0.64.169.80: tcp 0 > 13:44:36.361360 IP 192.168.1.50.63442 > 109.0.64.169.80: tcp 0 > 13:44:39.562045 IP 192.168.1.50.63442 > 109.0.64.169.80: tcp 0 > 13:44:42.761973 IP 192.168.1.50.63442 > 109.0.64.169.80: tcp 0 > 13:44:48.964016 IP 192.168.1.50.63442 > 109.0.64.169.80: tcp 0 > 13:45:01.163364 IP 192.168.1.50.63442 > 109.0.64.169.80: tcp 0 > 13:45:25.364943 IP 192.168.1.50.63442 > 109.0.64.169.80: tcp 0 > # tcpdump -tttteni pflog0 > 2021-09-11 13:44:26.960750 rule 0/0(match) [uid 100]: pass out on vsw0: > 192.168.1.50.63442 > 109.0.64.169.80: Flags [S], seq 559879806, win 65535, > options [mss 16344,nop,wscale 6,sackOK,TS val 31788278 ecr 0], length 0 So, again I am not sure if the issue is with routing or nat. Or even maybe something else. I enabled loud debugging in pf, but that gave nothing helpful. What are other options available to debug an issue like this ? K.