j knight wrote:
Bernd Bednarz wrote:
tcpdump from tun1 (interface wich the inputs comes)
router ~ $ tcpdump -ni tun1 port 80 and host 81.209.165.28
tcpdump: listening on tun1, link-type LOOP
11:55:40.099544 81.209.165.28.52486 > 84.158.142.59.80: S
1155228679:1155228679(0) win 5840 <mss 1452,sackOK,timestamp 472436333
0,nop,wscale 0> (DF)
11:55:43.099268 81.209.165.28.52486 > 84.158.142.59.80: S
1155228679:1155228679(0) win 5840 <mss 1452,sackOK,timestamp 472436633
0,nop,wscale 0> (DF)
---
tcpdump from tun0 (default gateway)
router ~ $ tcpdump -ni tun0 port 80 and host 81.209.165.28
tcpdump: listening on tun0, link-type LOOP
11:55:40.099991 84.158.142.59.80 > 81.209.165.28.52486: R 0:0(0) ack
1155228680 win 0 (DF)
11:55:43.099517 84.158.142.59.80 > 81.209.165.28.52486: R 0:0(0) ack 1
win 0 (DF)
Is this what you're expecting? Is 10.30.70.43 even listening on port 80?
Is 10.30.70.43 seeing the packets from 81.209.165.28?
The packet come trough 10.30.70.43 and it answers over its defaults gate
wich is the router where the two tuns are.
router ~ $ sysctl -a | grep source
net.inet.ip.sourceroute=1
I'm not sure why this would be enabled..? net.inet.ip.forwarding must be
enabled.
forward is enabled and I thought I have to use sourcerouting in kernel
to make this work but I will test it without.
In your first email you had these rules:
pass out on $dsl2 route-to ($dsl1 $gw1) from $ip1 to any
pass out on $dsl1 route-to ($dsl2 $gw2) from $ip2 to any
Why did you remove them?
because the reply-to rule make the same for me and I don't need both of
them. When I ping the router on tun1 the packets go trough tun1 with the
route-to oder reply-to and thatsway I only have the one rule reply-to
I'm not certain why you're seeing those packets on tun0 and not tun1.
The two rules above will solve the problem, however. I'm suspicious that
this is the problem, the two rules above don't catches this packets.
perhaps pf is generating the RST in which case the packet could be
bypassing the state table evaluation. This is why it's important to know
whether 10.30.70.43 is seeing the packets or not.
Yes the packets are anserwed by 10.30.70.43.
.joel
bbednarz
