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?
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.
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?
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
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.
.joel
