Re: [pfSense Support] interesting traffic is not encapsulated
Evgeny Yurchenko wrote: Evgeny Yurchenko wrote: Chris Buechler wrote: On Tue, Sep 22, 2009 at 11:10 PM, Evgeny Yurchenko evg.yu...@rogers.com wrote: I can not ping 10.29.11.1 or 10.29.11.2 from any host connected to LAN pfSense1. Traffic does not go over IPSec but instead natted and goes to Internet. On WAN (ng0): 20:29:13.951253 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 6706, length 40 20:29:19.451065 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 6962, length 40 20:29:24.950912 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 7218, length 40 Can anybody explain this? If it's initiated from the firewall, and initiated from a source IP that's part of the IPsec connection, it will traverse the IPsec. If you don't tell it where to initiate, and you don't have the static route described in the aforementioned FAQ, it will follow the system routing table which generally means it won't go over IPsec. I totally understand it and agree, but my purpose is to allow hosts from one subnet reach another (remote) subnet and this does not work. This trace is for the case when traffic initiated by PC 10.29.1.34 (connected to LAN pfSense1). I mentioned traffic initiated from the firewall only to demonstrate that IPSec tunnel is up and running. Eugene Interesting update. Host connected to LAN pfSense1 continuously pings LAN interface of pfSense2. Traffic is supposed to go over IPSec-tunnel LAN pfSense1:# tcpdump -ni fxp0 -n net 10.29.11.0/24 17:10:07.604717 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 8276, length 40 17:10:09.104694 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 8532, length 40 17:10:10.604652 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 8788, length 40 17:10:12.104580 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 9044, length 40 17:10:13.604540 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 9300, length 40 17:10:15.104483 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 9556, length 40 17:10:16.604445 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 9812, length 40 17:10:18.104359 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 10068, length 40 17:10:19.604352 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 10324, length 40 17:10:21.104285 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 10580, length 40 17:10:22.604232 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 10836, length 40 17:10:24.104175 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 11092, length 40 17:10:25.604131 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 11348, length 40 17:10:27.104047 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 11604, length 40 17:10:28.603996 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 11860, length 40 17:10:30.103990 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 12116, length 40 17:10:31.603892 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 12372, length 40 ^C 20 packets captured 2001 packets received by filter 0 packets dropped by kernel IPSec is totally disabled on pfSense1** WAN pfSense1: # tcpdump -ni ng0 host y.y.y.155 or net 10.29.11.0/24 17:10:07.604813 IP x.x.x.206.106 10.29.11.1: ICMP echo request, id 54116, seq 8276, length 40 17:10:09.104899 IP x.x.x.206.106 10.29.11.1: ICMP echo request, id 54116, seq 8532, length 40 17:10:10.604888 IP x.x.x.206.106 10.29.11.1: ICMP echo request, id 54116, seq 8788, length 40 Enable IPSec on pfSense1 * 17:10:12.363997 IP x.x.x.206.106.500 38.104.156.155.500: isakmp: phase 1 I agg 17:10:12.689959 IP 38.104.156.155.500 x.x.x.206.106.500: isakmp: phase 1 R agg 17:10:12.759339 IP x.x.x.206.106.500 y.y.y.155.500: isakmp: phase 1 I agg 17:10:12.760546 IP x.x.x.206.106.500 y.y.y.155.500: isakmp: phase 2/others I inf[E] 17:10:13.796275 IP x.x.x.206.106.500 y.y.y.155.500: isakmp: phase 2/others I oakley-quick[E] 17:10:14.010480 IP y.y.y.155.500 x.x.x.206.106.500: isakmp: phase 2/others R oakley-quick[E] 17:10:14.012456 IP x.x.x.206.106.500 y.y.y.155.500: isakmp: phase 2/others I oakley-quick[E] 17:10:15.105113 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x1), length 92 17:10:16.604921 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x2), length 92 17:10:18.104787 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x3), length 92 17:10:19.604818 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x4), length 92 17:10:21.104759 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x5), length 92 17:10:22.604735 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x6), length 92 17:10:24.104578 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x7), length 92 17:10:25.604655 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x8), length 92 17:10:27.104167 IP x.x.x.206.106 10.29.11.1: ICMP echo request, id
Re: [pfSense Support] interesting traffic is not encapsulated
Evgeny Yurchenko wrote: Chris Buechler wrote: On Tue, Sep 22, 2009 at 11:10 PM, Evgeny Yurchenko evg.yu...@rogers.com wrote: I can not ping 10.29.11.1 or 10.29.11.2 from any host connected to LAN pfSense1. Traffic does not go over IPSec but instead natted and goes to Internet. On WAN (ng0): 20:29:13.951253 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 6706, length 40 20:29:19.451065 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 6962, length 40 20:29:24.950912 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 7218, length 40 Can anybody explain this? If it's initiated from the firewall, and initiated from a source IP that's part of the IPsec connection, it will traverse the IPsec. If you don't tell it where to initiate, and you don't have the static route described in the aforementioned FAQ, it will follow the system routing table which generally means it won't go over IPsec. I totally understand it and agree, but my purpose is to allow hosts from one subnet reach another (remote) subnet and this does not work. This trace is for the case when traffic initiated by PC 10.29.1.34 (connected to LAN pfSense1). I mentioned traffic initiated from the firewall only to demonstrate that IPSec tunnel is up and running. Eugene Interesting update. Host connected to LAN pfSense1 continuously pings LAN interface of pfSense2. Traffic is supposed to go over IPSec-tunnel LAN pfSense1:# tcpdump -ni fxp0 -n net 10.29.11.0/24 17:10:07.604717 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 8276, length 40 17:10:09.104694 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 8532, length 40 17:10:10.604652 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 8788, length 40 17:10:12.104580 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 9044, length 40 17:10:13.604540 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 9300, length 40 17:10:15.104483 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 9556, length 40 17:10:16.604445 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 9812, length 40 17:10:18.104359 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 10068, length 40 17:10:19.604352 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 10324, length 40 17:10:21.104285 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 10580, length 40 17:10:22.604232 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 10836, length 40 17:10:24.104175 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 11092, length 40 17:10:25.604131 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 11348, length 40 17:10:27.104047 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 11604, length 40 17:10:28.603996 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 11860, length 40 17:10:30.103990 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 12116, length 40 17:10:31.603892 IP 10.29.1.34 10.29.11.1: ICMP echo request, id 1024, seq 12372, length 40 ^C 20 packets captured 2001 packets received by filter 0 packets dropped by kernel IPSec is totally disabled on pfSense1** WAN pfSense1: # tcpdump -ni ng0 host y.y.y.155 or net 10.29.11.0/24 17:10:07.604813 IP x.x.x.206.106 10.29.11.1: ICMP echo request, id 54116, seq 8276, length 40 17:10:09.104899 IP x.x.x.206.106 10.29.11.1: ICMP echo request, id 54116, seq 8532, length 40 17:10:10.604888 IP x.x.x.206.106 10.29.11.1: ICMP echo request, id 54116, seq 8788, length 40 Enable IPSec on pfSense1 * 17:10:12.363997 IP x.x.x.206.106.500 38.104.156.155.500: isakmp: phase 1 I agg 17:10:12.689959 IP 38.104.156.155.500 x.x.x.206.106.500: isakmp: phase 1 R agg 17:10:12.759339 IP x.x.x.206.106.500 y.y.y.155.500: isakmp: phase 1 I agg 17:10:12.760546 IP x.x.x.206.106.500 y.y.y.155.500: isakmp: phase 2/others I inf[E] 17:10:13.796275 IP x.x.x.206.106.500 y.y.y.155.500: isakmp: phase 2/others I oakley-quick[E] 17:10:14.010480 IP y.y.y.155.500 x.x.x.206.106.500: isakmp: phase 2/others R oakley-quick[E] 17:10:14.012456 IP x.x.x.206.106.500 y.y.y.155.500: isakmp: phase 2/others I oakley-quick[E] 17:10:15.105113 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x1), length 92 17:10:16.604921 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x2), length 92 17:10:18.104787 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x3), length 92 17:10:19.604818 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x4), length 92 17:10:21.104759 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x5), length 92 17:10:22.604735 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x6), length 92 17:10:24.104578 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x7), length 92 17:10:25.604655 IP x.x.x.206.106 y.y.y.155: ESP(spi=0x0d9554c6,seq=0x8), length 92 17:10:27.104167 IP x.x.x.206.106 10.29.11.1: ICMP echo request, id 54116, seq 11604, length 40
Re: [pfSense Support] interesting traffic is not encapsulated
On Tue, Sep 22, 2009 at 12:32 PM, Evgeny Yurchenko evg.yu...@rogers.com wrote: I know it looks stupid, but... 1.2.3-RC1 LAN=10.29.1.19/24 WAN(PPPoE)=x.x.x.106 remote LAN=10.29.11.1/24 remote WAN=x.x.x.225 Tunnel is up. When I do from pfSense itself ping -S 10.29.1.19 10.29.11.1 everything goes well, ESP packets and ping reply. When I do ping 10.29.11.1 from 10.29.1.34 connected to LAN traffic goes NATed out of WAN: 18:51:33.862273 IP x.x.x.106 10.29.11.1: ICMP echo request, id 22499, seq 57389, length 40 10.29.1.0/24[any] 10.29.1.19[any] any in none spid=45 seq=3 pid=4536 refcnt=1 10.29.11.0/24[any] 10.29.1.0/24[any] any in ipsec esp/tunnel/x.x.x.225-x.x.x.106/unique#16418 spid=48 seq=2 pid=4536 refcnt=1 10.29.1.19[any] 10.29.1.0/24[any] any out none spid=46 seq=1 pid=4536 refcnt=1 10.29.1.0/24[any] 10.29.11.0/24[any] any out ipsec esp/tunnel/x.x.x.106-x.x.x.225/unique#16417 spid=47 seq=0 pid=4536 refcnt=1 Pleeease any hint -( - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org That is normal. Traffic on the firewall itself prefers the system routing table. Clients behind the firewall will prefer the IPSEC tunnel. Pretty sure that is documented somewhere on the doc site. Scott - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] interesting traffic is not encapsulated
Scott Ullrich wrote: That is normal. Traffic on the firewall itself prefers the system routing table. Clients behind the firewall will prefer the IPSEC tunnel. Pretty sure that is documented somewhere on the doc site. Scott So, it is impossible to use IPSec with PPPoE on WAN? Eugene - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] interesting traffic is not encapsulated
On Tue, Sep 22, 2009 at 12:39 PM, Evgeny Yurchenko evg.yu...@rogers.com wrote: So, it is impossible to use IPSec with PPPoE on WAN? Eugene That would be news to me. It should work fine. Scott - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] interesting traffic is not encapsulated
Evgeny Yurchenko wrote: Scott Ullrich wrote: That is normal. Traffic on the firewall itself prefers the system routing table. Clients behind the firewall will prefer the IPSEC tunnel. Pretty sure that is documented somewhere on the doc site. Scott So, it is impossible to use IPSec with PPPoE on WAN? Eugene Then sorry Scott, I do not understand your statement: Traffic on the firewall itself prefers the system routing table. Clients behind the firewall will prefer the IPSEC tunnel. In my case traffic initiated on the firewall itself goes over the tunnel, client behind firewall goes over normal routing table/nat while it must go over the tunnel. And I've almost broken my head trying to understand why. Eugene - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] interesting traffic is not encapsulated
On Tue, Sep 22, 2009 at 12:46 PM, Evgeny Yurchenko evg.yu...@rogers.com wrote: Then sorry Scott, I do not understand your statement: Traffic on the firewall itself prefers the system routing table. Clients behind the firewall will prefer the IPSEC tunnel. In my case traffic initiated on the firewall itself goes over the tunnel, client behind firewall goes over normal routing table/nat while it must go over the tunnel. And I've almost broken my head trying to understand why. Sorry, I meant when you are pinging from the firewall itself. Double check your subnet information. This should work and I know folks running IPSEC on PPPoE hosts. If you continue to have problems we need more information such as the IPSEC SPD/SAD entries. Scott - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] interesting traffic is not encapsulated
On 22/09/09 17:36, Scott Ullrich wrote: That is normal. Traffic on the firewall itself prefers the system routing table. Clients behind the firewall will prefer the IPSEC tunnel. Pretty sure that is documented somewhere on the doc site. if you want connections initiated by the firewall to go over the IPSEC tunnel you have to add a static route to the remote LAN via the local LAN IP. e.g. if remote network is 10.20.30/24 and lan is 10.10.10.1 the static route looks like this... INTERFACE NETWORK GATEWAY LAN 10.20.30.0/24 10.10.10.1 however, the OP's problem seems to be a different one, so I think he has the wrong associations? might need to restart IPSEC on each end to be sure I have found it very useful to create an openvpn tunnel on remote firewalls but without routing (so that it's private between the two end-points), so that if the IPSEC tunnel goes wonky you can always ssh in and port forward to fix things! - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] interesting traffic is not encapsulated
Scott Ullrich wrote: On Tue, Sep 22, 2009 at 12:46 PM, Evgeny Yurchenko evg.yu...@rogers.com wrote: Then sorry Scott, I do not understand your statement: Traffic on the firewall itself prefers the system routing table. Clients behind the firewall will prefer the IPSEC tunnel. In my case traffic initiated on the firewall itself goes over the tunnel, client behind firewall goes over normal routing table/nat while it must go over the tunnel. And I've almost broken my head trying to understand why. Sorry, I meant when you are pinging from the firewall itself. Double check your subnet information. This should work and I know folks running IPSEC on PPPoE hosts. If you continue to have problems we need more information such as the IPSEC SPD/SAD entries. Scott I know it must work but I've spent many hours already trying to figure out why it does not... -( Currently I have: # setkey -PD 10.29.1.0/24[any] 10.29.1.19[any] any in none spid=55 seq=3 pid=30386 refcnt=1 10.29.11.0/24[any] 10.29.1.0/24[any] any in ipsec esp/tunnel/y.y.y.155-x.x.x.106/unique#16426 spid=58 seq=2 pid=30386 refcnt=1 10.29.1.19[any] 10.29.1.0/24[any] any out none spid=56 seq=1 pid=30386 refcnt=1 10.29.1.0/24[any] 10.29.11.0/24[any] any out ipsec esp/tunnel/x.x.x.106-y.y.y.155/unique#16425 spid=57 seq=0 pid=30386 refcnt=1 # setkey -D x.x.x.106 y.y.y.155 esp mode=any spi=122888134(0x07531fc6) reqid=16425(0x4029) E: 3des-cbc a8c0fd24 d6d2ae24 8f59f03d d97e3483 e6e36bd6 54ed54d0 A: hmac-sha1 3c8a1c12 452eb445 56a0e7b0 4212e329 caae4b23 seq=0x replay=4 flags=0x state=mature created: Sep 22 20:50:24 2009 current: Sep 22 21:04:34 2009 diff: 850(s)hard: 3600(s) soft: 2880(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0hard: 0 soft: 0 sadb_seq=2 pid=30402 refcnt=1 y.y.y.155 x.x.x.106 esp mode=tunnel spi=179125587(0x0aad3d53) reqid=16426(0x402a) E: 3des-cbc 4958801c 50167ed7 7dd51564 914c1669 520c9fbe 9275234e A: hmac-sha1 aca2d1d8 5a6b fcce17a6 3f25d3c8 7d36179c seq=0x replay=4 flags=0x state=mature created: Sep 22 20:50:24 2009 current: Sep 22 21:04:34 2009 diff: 850(s)hard: 3600(s) soft: 2880(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0hard: 0 soft: 0 sadb_seq=0 pid=30402 refcnt=1 # - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] interesting traffic is not encapsulated
Paul Mansfield wrote: On 22/09/09 17:36, Scott Ullrich wrote: That is normal. Traffic on the firewall itself prefers the system routing table. Clients behind the firewall will prefer the IPSEC tunnel. Pretty sure that is documented somewhere on the doc site. if you want connections initiated by the firewall to go over the IPSEC tunnel you have to add a static route to the remote LAN via the local LAN IP. e.g. if remote network is 10.20.30/24 and lan is 10.10.10.1 the static route looks like this... INTERFACE NETWORK GATEWAY LAN 10.20.30.0/24 10.10.10.1 Sorry, it does not make much sense to me. You can have this route but it will never work. Eugene. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] interesting traffic is not encapsulated
Chris Buechler wrote: On Tue, Sep 22, 2009 at 6:36 PM, Evgeny Yurchenko evg.yu...@rogers.com wrote: Paul Mansfield wrote: On 22/09/09 17:36, Scott Ullrich wrote: That is normal. Traffic on the firewall itself prefers the system routing table. Clients behind the firewall will prefer the IPSEC tunnel. Pretty sure that is documented somewhere on the doc site. if you want connections initiated by the firewall to go over the IPSEC tunnel you have to add a static route to the remote LAN via the local LAN IP. e.g. if remote network is 10.20.30/24 and lan is 10.10.10.1 the static route looks like this... INTERFACE NETWORK GATEWAY LAN 10.20.30.0/24 10.10.10.1 Sorry, it does not make much sense to me. You can have this route but it will never work. Yes it does. It's in the FAQ. http://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP%2C_use_syslog%2C_NTP%2C_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN%3F Probably my explanation is poor... I'll try again 10.29.1.3410.29.1.19/24 LAN pfSense1 WAN PPPoE x.x.x.106 Internet---y.y.y.155 WAN pfSense2 LAN 10.29.11.1/2410.29.11.2 IPSec between 10.29.1.0/24 and 10.29.11.0/24. I can ping 10.29.1.19 from 10.29.11.2. I can not ping 10.29.1.34 from 10.29.11.2 I can ping 10.29.11.1 and 10.29.11.2 from pfSense1 itself issuing command ping -S 10.29.1.19 10.29.11.1. Traffic goes over IPSec tunnel. I do not need any static routes for that. On WAN (ng0): 20:20:41.404778 IP x.x.x.106 y.y.y.155: ESP(spi=0x0cf5335a,seq=0x26), length 116 20:20:41.584349 IP y.y.y.155 x.x.x.106: ESP(spi=0x063d52eb,seq=0x18), length 116 I can not ping 10.29.11.1 or 10.29.11.2 from any host connected to LAN pfSense1. Traffic does not go over IPSec but instead natted and goes to Internet. On WAN (ng0): 20:29:13.951253 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 6706, length 40 20:29:19.451065 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 6962, length 40 20:29:24.950912 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 7218, length 40 Can anybody explain this? Thanks for attention. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] interesting traffic is not encapsulated
On Tue, Sep 22, 2009 at 11:10 PM, Evgeny Yurchenko evg.yu...@rogers.com wrote: I can not ping 10.29.11.1 or 10.29.11.2 from any host connected to LAN pfSense1. Traffic does not go over IPSec but instead natted and goes to Internet. On WAN (ng0): 20:29:13.951253 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 6706, length 40 20:29:19.451065 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 6962, length 40 20:29:24.950912 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 7218, length 40 Can anybody explain this? If it's initiated from the firewall, and initiated from a source IP that's part of the IPsec connection, it will traverse the IPsec. If you don't tell it where to initiate, and you don't have the static route described in the aforementioned FAQ, it will follow the system routing table which generally means it won't go over IPsec. - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] interesting traffic is not encapsulated
Chris Buechler wrote: On Tue, Sep 22, 2009 at 11:10 PM, Evgeny Yurchenko evg.yu...@rogers.com wrote: I can not ping 10.29.11.1 or 10.29.11.2 from any host connected to LAN pfSense1. Traffic does not go over IPSec but instead natted and goes to Internet. On WAN (ng0): 20:29:13.951253 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 6706, length 40 20:29:19.451065 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 6962, length 40 20:29:24.950912 IP x.x.x.106 10.29.11.1: ICMP echo request, id 1781, seq 7218, length 40 Can anybody explain this? If it's initiated from the firewall, and initiated from a source IP that's part of the IPsec connection, it will traverse the IPsec. If you don't tell it where to initiate, and you don't have the static route described in the aforementioned FAQ, it will follow the system routing table which generally means it won't go over IPsec. I totally understand it and agree, but my purpose is to allow hosts from one subnet reach another (remote) subnet and this does not work. This trace is for the case when traffic initiated by PC 10.29.1.34 (connected to LAN pfSense1). I mentioned traffic initiated from the firewall only to demonstrate that IPSec tunnel is up and running. Eugene - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
