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.